| 00:01.13 | UndrWater | shr-today config is gone...is there a new one, or does it get configured differently? |
| 00:34.27 | *** join/#openmoko gonzoism (n=gonzoism@rrcs-71-41-206-194.sw.biz.rr.com) |
| 00:36.28 | *** join/#openmoko djj (i=djj@xob.kapsi.fi) |
| 00:52.28 | *** join/#openmoko azaghal (n=azaghal@91.148.113.131) |
| 01:05.29 | *** join/#openmoko azaghal_ (n=azaghal@222.228.178.212.adsl.dyn.beotel.net) |
| 01:12.51 | *** join/#openmoko peter-b (n=peter_b@mnch-5d86ec69.pool.mediaWays.net) |
| 01:15.49 | *** join/#openmoko azaghal_1 (n=azaghal@195.252.105.42) |
| 01:41.58 | *** join/#openmoko CVirus (n=Satan@62.135.96.237) |
| 01:44.18 | *** part/#openmoko der-lehmann (n=stefan@188-192-133-169-dynip.superkabel.de) |
| 01:48.42 | *** join/#openmoko ssam (n=ssam@87.127.117.246) |
| 01:54.04 | *** join/#openmoko vanous123 (n=vanous@ip-85-93-174-26.wscnet.cz) |
| 02:06.44 | *** join/#openmoko Defiant (i=erik@e179196167.adsl.alicedsl.de) |
| 02:22.41 | *** join/#openmoko emacsian (n=ram@122.167.89.156) |
| 02:42.40 | *** join/#openmoko pablomino (n=pablo@r190-135-221-109.dialup.adsl.anteldata.net.uy) |
| 02:42.55 | *** part/#openmoko pablomino (n=pablo@r190-135-221-109.dialup.adsl.anteldata.net.uy) |
| 02:44.07 | *** join/#openmoko chomwitt_ (n=chomwitt@ppp-94-66-133-43.home.otenet.gr) |
| 02:52.52 | *** join/#openmoko redarrow_2 (n=thomas@unaffiliated/redarrow) |
| 03:03.17 | *** join/#openmoko KenYoung (n=Ken@pool-151-199-60-104.bos.east.verizon.net) |
| 03:12.24 | KenYoung | ping raster |
| 03:15.41 | *** join/#openmoko azaghal (n=azaghal@195.252.105.42) |
| 03:20.05 | *** join/#openmoko eolson (n=eolson@c-24-13-244-61.hsd1.il.comcast.net) |
| 03:22.50 | *** join/#openmoko pcfe (n=pcfe@a83-245-163-56.elisa-laajakaista.fi) |
| 03:49.05 | *** join/#openmoko aloril_ (n=aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
| 04:04.10 | *** join/#openmoko kkb110 (n=kkb110@pool-173-59-51-194.phlapa.fios.verizon.net) |
| 04:04.27 | *** join/#openmoko rhaeder (n=rhaeder@188.109.244.80) |
| 04:38.39 | *** join/#openmoko SpeedEvil (n=user@tor/regular/SpeedEvil) |
| 04:40.28 | *** join/#openmoko chihchun (n=nnchihch@u7.hlc.edu.tw) |
| 04:46.28 | *** join/#openmoko everslick (n=clemens@91-113-124-4.adsl.highway.telekom.at) |
| 04:48.42 | *** join/#openmoko batti112 (n=batti@dslb-088-078-078-226.pools.arcor-ip.net) |
| 05:42.12 | *** join/#openmoko Docscrutemp (n=Joerg_rw@82.113.106.223) |
| 05:49.37 | *** join/#openmoko joerg_42 (n=jr-N810@200.194.116.85.dsl.manitu.net) |
| 06:00.55 | *** join/#openmoko Docscrutemp (n=Joerg_rw@82.113.106.217) |
| 06:06.59 | *** join/#openmoko dvermd (n=roudoudo@78.234.93.192) |
| 06:27.45 | raster | kennyz: boo |
| 06:27.50 | raster | oops |
| 06:27.55 | raster | tab-complete wrong... |
| 06:31.27 | *** join/#openmoko DocScrutinizer51 (n=Joerg_rw@82.113.106.217) |
| 06:42.52 | rhkfin | fail |
| 06:43.35 | rhkfin | so once again - is anyone using shr-testing and could tell me the good, the bad and the ugly of it..? |
| 06:54.19 | *** join/#openmoko Kamping_Kaiser (i=kgoetz@gnewsense/friend/kgoetz) |
| 07:16.43 | *** join/#openmoko DocScrutinizer51 (n=Joerg_rw@82.113.106.217) |
| 07:28.00 | *** join/#openmoko toi (n=toi@d54C2A96D.access.telenet.be) |
| 08:07.05 | *** join/#openmoko Kame2 (n=manuel@port-92-196-30-116.dynamic.qsc.de) |
| 08:37.18 | *** join/#openmoko pa4wdh (n=pa4wdh@lt30598-lnx.ipv6.pa4wdh.nl.eu.org) |
| 08:41.14 | *** join/#openmoko radekp (n=radek@63.120.broadband10.iol.cz) |
| 08:44.11 | *** join/#openmoko der-lehmann (n=stefan@188-192-133-169-dynip.superkabel.de) |
| 08:53.04 | *** join/#openmoko Batchy (n=batchy@AVelizy-155-1-65-185.w86-217.abo.wanadoo.fr) |
| 09:05.00 | *** join/#openmoko Gabrys (n=Gabrys@77-254-66-61.adsl.inetia.pl) |
| 09:25.01 | *** join/#openmoko samgee (n=samgee@fsf/member/samgee) |
| 09:26.37 | *** join/#openmoko Heinervdm (n=thomas@pD9E14AAB.dip.t-dialin.net) |
| 09:27.09 | *** join/#openmoko ssam (n=ssam@87.127.117.246) |
| 09:31.07 | *** join/#openmoko CVirus (n=Satan@41.130.214.240) |
| 09:37.24 | *** join/#openmoko gunbritt (n=arfmarf@unaffiliated/gunbritt) |
| 09:39.12 | *** join/#openmoko azaghal (n=azaghal@91.148.115.68) |
| 09:46.55 | *** join/#openmoko md2k7 (n=david@h081217039232.dyn.cm.kabsi.at) |
| 10:04.17 | *** join/#openmoko gunbritt (n=arfmarf@unaffiliated/gunbritt) |
| 10:14.59 | *** join/#openmoko amarsh04 (n=amarsh04@ppp118-210-249-193.lns20.adl6.internode.on.net) |
| 10:15.12 | *** join/#openmoko emacsian (n=ram@122.167.246.214) |
| 10:19.46 | *** join/#openmoko larsc (n=lars@rzdspc10.informatik.uni-hamburg.de) |
| 10:20.05 | *** join/#openmoko Gabrys (n=Gabrys@77-254-66-61.adsl.inetia.pl) |
| 10:29.44 | *** join/#openmoko Defiant (i=erik@g224068008.adsl.alicedsl.de) |
| 10:32.42 | *** join/#openmoko dns53 (n=dns@ppp246-215.static.internode.on.net) |
| 10:34.47 | *** join/#openmoko nio_ (n=nio@d594e4f0.dsl.concepts.nl) |
| 10:35.59 | *** join/#openmoko gena2x (n=gena2x@bsdmn.com) |
| 10:41.11 | *** join/#openmoko panicking (n=Michael@77.224.194.88) |
| 10:41.16 | panicking | PaulFertser, hi |
| 10:41.23 | panicking | can you take a look of this patch? |
| 10:41.24 | PaulFertser | panicking: hey |
| 10:41.50 | PaulFertser | panicking: i can try to look at it right now, yes. Not promising i have enough skills to do anything useful but still :) |
| 10:42.07 | PaulFertser | panicking: btw, can you tell me a little about FCSE? |
| 10:42.17 | PaulFertser | panicking: did you manage to get any measureable benefits? |
| 10:42.18 | *** join/#openmoko Defiant- (i=erik@f054023190.adsl.alicedsl.de) |
| 10:42.18 | panicking | http://pastebin.com/m2774c980 |
| 10:42.45 | *** join/#openmoko beneth` (n=beneth`@beneth.fr) |
| 10:44.56 | panicking | this is the other one |
| 10:44.57 | panicking | http://pastebin.com/m48cfe9d5 |
| 10:45.05 | PaulFertser | panicking: ok, will look at it right now, thanks a lot |
| 10:45.15 | panicking | I think that the next is not good in general |
| 10:45.31 | panicking | When the system is poweroff I don't want |
| 10:45.36 | panicking | wake up for alarm |
| 10:45.50 | panicking | Does the people use alarm to poweron the mobile? |
| 10:46.39 | PaulFertser | panicking: i think mostly no, they use alarm to wake from suspend. |
| 10:47.20 | panicking | I'm scared about application that set an RTC_ALARM and we don't wake |
| 10:47.26 | panicking | up for poweroff |
| 10:47.54 | panicking | so the second patch avoid power on on rtc alarm |
| 10:48.37 | PaulFertser | panicking: can you please rephrase the last statement? |
| 10:49.09 | panicking | When you power off the device with the second patch |
| 10:49.14 | panicking | the system doen't wake up |
| 10:49.32 | panicking | for a pending (bogus) rtc alarm set by some application |
| 10:49.46 | panicking | that basiscally is used for suspend |
| 10:50.03 | PaulFertser | panicking: why can an application set a bogus alarm? |
| 10:50.05 | *** join/#openmoko md2k7 (n=david@h081217039232.dyn.cm.kabsi.at) |
| 10:50.25 | panicking | for example android set rtc alarm for advice of incoming sms |
| 10:50.30 | panicking | to wake up for suspend |
| 10:50.34 | panicking | mms |
| 10:50.44 | panicking | or somenthig to advice the user |
| 10:50.47 | panicking | you have somenthing |
| 10:50.49 | *** join/#openmoko ssam (n=ssam@87.127.117.246) |
| 10:51.03 | panicking | it can be used for reapet vibrate |
| 10:51.06 | panicking | led blink |
| 10:51.07 | panicking | etc |
| 10:51.18 | panicking | but if you shutdown the device |
| 10:51.18 | PaulFertser | panicking: so why doesn't it disable it before powering off? |
| 10:51.43 | panicking | because the expecting beahvior of the framework is to wakeup |
| 10:51.48 | panicking | for suspend and not for poweroff |
| 10:51.53 | panicking | I would like to know |
| 10:52.04 | panicking | if this beahvior is the same in other distribuition |
| 10:53.05 | PaulFertser | panicking: when you shutdown the device usual way you have enough hooks both in userspace and in the kernel to do the necessary cleanup, right? |
| 10:53.47 | PaulFertser | panicking: if the framework expects to be able to turn the device on with RTC alarm, it should just work. If it doesn't want that, it should disable the alarm on shutdown. What is the problem? |
| 10:54.01 | panicking | ok, |
| 10:54.05 | panicking | I understand |
| 10:54.15 | panicking | and what do you think about the first one patch |
| 10:54.15 | panicking | ? |
| 10:54.34 | panicking | is it correct the new mask |
| 10:54.34 | panicking | ? |
| 10:56.38 | PaulFertser | panicking: (qi patch) 0xd3 there looks definetely bogus, since exton1 is tied to VB_SYS. And yet have you seen the device waken up by that? It's tied to VB_SYS hard, where can a glitch come from? |
| 10:57.24 | PaulFertser | panicking: i mean the patch looks perfectly correct but the mistake should be harmless anyway. |
| 10:57.25 | panicking | Yes, but sometimes people report wakeup. So the reason can be |
| 10:57.32 | panicking | a wrong RTC clock |
| 10:57.34 | gena2x | hi, guys. have a problem on shr-unstable upgrade: [/usr/lib/opkg/info/phonefsod.postinst: line 7: update-rc.d: not found], anyone know how where update-rc.d? |
| 10:57.35 | panicking | or a glitch |
| 10:57.45 | PaulFertser | panicking: just the comment should be altered. |
| 10:57.59 | PaulFertser | panicking: i doubt there can be a glitch on a 10k-tied line. |
| 10:58.26 | PaulFertser | panicking: also if you say "wakeup" it most probably comes from e.g. wifi WOL rather than exton1. |
| 10:58.43 | PaulFertser | panicking: the kernel already has enough diagnostics to be able to tell for sure the wakeup reason, you know. |
| 10:58.56 | panicking | yes I know, but I can't answer to the user |
| 10:59.01 | *** join/#openmoko Defiant (i=erik@e177138105.adsl.alicedsl.de) |
| 10:59.02 | panicking | take a look on the sysfs |
| 10:59.06 | panicking | and report me the reason |
| 10:59.25 | PaulFertser | panicking: why? |
| 10:59.26 | panicking | ok so the glitch is impossible |
| 10:59.39 | PaulFertser | panicking: A has no sysfs mounted or what? |
| 10:59.41 | panicking | Because I want that gta02 can be used as a mobile |
| 10:59.54 | panicking | not only for people that want to |
| 11:00.00 | panicking | cat sysfs |
| 11:00.04 | PaulFertser | panicking: so you compile out sysfs support or what? |
| 11:00.04 | panicking | yes is mounted |
| 11:00.07 | PaulFertser | :))) |
| 11:00.17 | *** join/#openmoko vanous123 (n=vanous@ip-85-93-174-26.wscnet.cz) |
| 11:00.55 | panicking | This is my idea: |
| 11:00.55 | gena2x | panicking: Same mistake om did. They target geek phone to ordinary people. |
| 11:01.17 | PaulFertser | panicking: wifi wol would be interesting to debug in fact. |
| 11:01.27 | PaulFertser | panicking: it's one of the things i wanted to do myself but was too lazy. |
| 11:01.47 | panicking | Can you describe the situation? |
| 11:02.04 | panicking | On thusday I will receive a new debug board |
| 11:02.04 | PaulFertser | panicking: but from what i saw it looks quite possibly for it to work and it looks like when wifi is off it can produce spurious wake-ups, i saw the code and schematics. |
| 11:02.11 | panicking | so I can work on 2.6.3x |
| 11:04.03 | panicking | Ok, so why put in out |
| 11:04.08 | panicking | the pin during suspend |
| 11:04.09 | panicking | ? |
| 11:04.23 | *** join/#openmoko thrashold (n=europan@3mhz.net) |
| 11:05.01 | *** join/#openmoko toer (i=tore@179.81-166-86.customer.lyse.net) |
| 11:05.45 | panicking | gena2x, the error was to have a mobile that was not stable |
| 11:05.48 | panicking | for 2 year |
| 11:05.57 | panicking | in hw and sw |
| 11:07.29 | SpeedEvil | sw mainly |
| 11:07.44 | SpeedEvil | gta01 was - pretty much - usable as a phone from a hw pov |
| 11:08.21 | SpeedEvil | some minor tweaks would have been nice - but the software stack - the UI - in march 2007 was usableish - though needed a tiny bit of fixing - for basic SMS and call. |
| 11:08.48 | gena2x | panicking: nope, it's easy to predict that completely new very complex hw with completely new software cann't be stable. |
| 11:08.51 | SpeedEvil | Get it working, though unpretty, and the kernel fixed, and a minor hardware bugfix release possibly - and you're ready for xmas 2007 |
| 11:09.05 | SpeedEvil | gena2x: rubbish. |
| 11:09.07 | SpeedEvil | IMO |
| 11:09.37 | panicking | yes, but when android (that was a complete mobile framework) |
| 11:09.37 | SpeedEvil | There is complex hardware that is hard to get right, and concentrating on shiny UI when the kernel is unstable in many ways. |
| 11:09.46 | gena2x | panicking: but all that boot time optimizations, boot pictures only dust to someone's face. |
| 11:09.50 | panicking | went out |
| 11:09.55 | panicking | nobody care about it |
| 11:11.24 | SpeedEvil | panicking: Still - I would have bought one in xmas 2007 - released with a basic stack and GTK |
| 11:11.33 | SpeedEvil | (if I hadn't bought earlier of course) |
| 11:12.09 | gena2x | ok, in fact i am wrong, hw was not new. |
| 11:12.22 | panicking | Yes, the problem was that it the first or (i don't know) linux mobile |
| 11:12.25 | panicking | is it correct? |
| 11:13.07 | gena2x | in fact linux was used in mobile long before om. |
| 11:14.08 | gena2x | panicking: how your android with new kernel? |
| 11:14.57 | SpeedEvil | It was the first linux mobile with an open stack. |
| 11:15.04 | panicking | I think that is quite good, but I have the idea it can be better |
| 11:15.22 | panicking | but no time a lot of time to busrt performace |
| 11:15.32 | panicking | we have 60 or 70 issue |
| 11:15.36 | panicking | on the bugtrack |
| 11:15.36 | *** join/#openmoko azaghal_ (n=azaghal@195.252.105.56) |
| 11:15.42 | panicking | some of them are feauture |
| 11:16.01 | panicking | so wifi is ok |
| 11:16.18 | panicking | to many things to say |
| 11:16.20 | panicking | let's try |
| 11:16.35 | panicking | wait for a daily build |
| 11:16.41 | panicking | because I fix somenthing now |
| 11:16.44 | panicking | and install it |
| 11:17.22 | panicking | I think that is possible to use 440mhz |
| 11:17.26 | panicking | frequency too |
| 11:18.59 | gena2x | panicking: I like you point of view on optimization :) But before reflashing once again I am planning to do something useful :) |
| 11:22.00 | *** join/#openmoko Gabrys (n=Gabrys@77-254-66-61.adsl.inetia.pl) |
| 11:23.40 | *** join/#openmoko Sargun (n=Sargun@atarack/Staff/Sargun) |
| 11:23.48 | gena2x | For example I think that true developer phone should have cpu and memory load indicatiors, and better to have percent bettery and recieving signal strength indicatior |
| 11:25.13 | gena2x | So it's easy to understand what's going on device. |
| 11:27.15 | *** join/#openmoko dos1 (n=dos@unaffiliated/dos1) |
| 11:28.33 | gena2x | who knows which package start-stop-daemon and update-rc.d belongs to in shr? |
| 11:33.48 | gena2x | and what to do with fso-apm/apm... |
| 11:40.36 | gena2x | Seem i am asking too many simple questions... |
| 11:43.33 | *** part/#openmoko der-lehmann (n=stefan@188-192-133-169-dynip.superkabel.de) |
| 11:44.46 | *** join/#openmoko Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 11:45.19 | *** join/#openmoko bentob0x (n=laurent@ip-213-49-80-75.dsl.scarlet.be) |
| 11:45.19 | *** join/#openmoko gena2x (n=gena2x@bsdmn.com) |
| 11:47.49 | gena2x | Ok, last question, not so simple: I am getting host lockup on openmoko unplug. My host is x86-64 debian with self compiled kernel. I can't handle this problem myself. I post mail linux-usb, but noone seem can take care of this problem. What to do with it? Do anyone have similar problem? |
| 11:48.24 | *** join/#openmoko azaghal (n=azaghal@91.148.113.121) |
| 11:48.58 | Weiss | gena2x: I get fairly regular oopses when plugging it in, but unplugging+re-plugging fixes it. maybe it's related |
| 11:50.14 | gena2x | here is my mail: http://www.spinics.net/lists/linux-usb/msg24453.html |
| 11:52.18 | gena2x | Anyone can recommend the way that whould I do to have this problem fixed? |
| 11:53.32 | gena2x | Weiss: Mb. and you lucky. I am getting complete lockup. |
| 11:53.54 | gena2x | Weiss: opses in host kernel? |
| 11:53.56 | Weiss | the most useful thing you can do at this point would be to bisect and find the revision where the problem started |
| 11:53.59 | Weiss | gena2x: yep |
| 11:54.43 | gena2x | Weiss: with backtrace? |
| 11:55.20 | gena2x | Weiss: so i have to dig up into usb subsystem... |
| 11:55.20 | Weiss | git bisect |
| 11:56.00 | gena2x | Weiss: ok, i'll try this opensource way... |
| 11:56.30 | Weiss | start by maybe going back to 2.6.30 and seeing if it happens there, if it doesn't, run git bisect to narrow it down between those versions (this doesn't take as long as it sounds, but count on an entire evening) |
| 11:57.00 | gena2x | Weiss: mb this is because of kernel change at openmoko |
| 11:57.08 | Weiss | the people developing the subsystem can usually fix it very quickly if you can give then this information |
| 11:57.11 | Weiss | them* |
| 11:57.45 | Weiss | maybe an OM kernel change made it show up, but a kernel oops ALWAYS represents a bug in that kernel |
| 11:58.30 | gena2x | Weiss: i sent mail to maintainer, he asked me to retest on latest rc, I retested, posted and nothing happened. |
| 11:58.51 | gena2x | ;9 |
| 11:58.53 | gena2x | :( |
| 11:59.11 | Weiss | the problem still existed? |
| 12:00.50 | gena2x | Weiss: I should retest 5th time on latest kernel to find out that |
| 12:01.23 | panicking | do it in qemu |
| 12:01.29 | panicking | freeeze the qemu machine |
| 12:01.48 | panicking | and test the qemu machine |
| 12:01.53 | gena2x | panicking: Interesting idea. |
| 12:02.06 | panicking | but it can not be freeze :D |
| 12:02.17 | panicking | -usb -usbdevice:host:id:xx |
| 12:02.40 | gena2x | panicking: yes, I know that qemu can do usb |
| 12:03.22 | *** join/#openmoko naeg (n=naeg@194.208.239.170) |
| 12:03.44 | *** join/#openmoko vanous123 (n=vanous@ip-85-93-174-26.wscnet.cz) |
| 12:04.21 | *** join/#openmoko alfatangoxt (n=michele@host88-205-dynamic.19-79-r.retail.telecomitalia.it) |
| 12:05.01 | gena2x | panicking: thanks, i had to realise it by myself. |
| 12:05.38 | gena2x | Weiss: So I'll try latest 32.1... |
| 12:06.21 | panicking | sorry :) |
| 12:06.26 | panicking | I would like to helop |
| 12:07.19 | gena2x | panicking: really never mind against right ideas :) |
| 12:07.58 | panicking | Do you have stack protector in your config |
| 12:07.59 | panicking | ? |
| 12:09.10 | gena2x | panicking: no |
| 12:09.41 | panicking | can you activate it |
| 12:11.45 | *** join/#openmoko emacsian (n=ram@122.167.246.214) |
| 12:12.22 | PaulFertser | panicking: so, do you agree i apply the Qi patch (amending the comment) but not the kernel patch since we agreed it's wrong? |
| 12:12.44 | gena2x | panicking: ... read about it. nice idea. |
| 12:13.52 | Weiss | gena2x: try to see it from the developer's perspective: "oh crap, someone found a bug. I wonder if went away with the latest version - if so, I don't have to fix it. Nope, still happens. I have no idea what caused it and can't reproduce it" |
| 12:14.03 | PaulFertser | panicking: so what about FCSE? Does it work at all given all the limitations (pid and address space)? I assume you run in "best effort mode" so what are the measurable benefits? |
| 12:14.46 | panicking | I have no measure yet, because there are to many changes and I must isolate |
| 12:14.49 | panicking | one each one |
| 12:14.58 | Weiss | gena2x: so YOU need to go back in time and see if it happened with EARLIER versions. if you can find a time where the bug didn't happen, you can step forward and find out where it was introduced. That's the most valuable information for the developer. "git bisect" can help you do it much faster |
| 12:14.59 | panicking | can be a good computation of ram refresh rate too |
| 12:15.15 | panicking | git bisect and qemu |
| 12:15.19 | panicking | if you can reproduce it |
| 12:16.18 | PaulFertser | Weiss: isn't oops on host usually easy enough to debug without bisecting? |
| 12:17.23 | gena2x | Weiss: I already so it from developer perspective, as a developer first i thought "crap, it now hangs, some bug in kernel, guess this will be fixed in next version", wait... next version, compile retest, no fix... ok. How to report bugs? mail maintainer? ok... big mail... answer 'please retest and mail to linux-usb'... ok, i know developer perspective... retest... other big mail... wait for answer... |
| 12:17.24 | PaulFertser | But i see, it's not oops this time. |
| 12:18.01 | PaulFertser | gena2x: have you tried reproducing with bleeding-edge kernel? |
| 12:18.37 | gena2x | Ok, now I have plan. Thanks all :) |
| 12:18.38 | Weiss | PaulFertser: perhaps..but a bisection is always very valuable - means the developer can go straight to the bit where they broke it.. |
| 12:18.58 | PaulFertser | Weiss: yes, indeed. USB stuff is hard to dive in anyway even for an experienced person :| |
| 12:19.09 | *** join/#openmoko Ainulindale (n=ainu@calaquendi.org) |
| 12:19.23 | PaulFertser | gena2x: sorry for useless questions, i see now you tried 32-rc8 as well. :) |
| 12:19.59 | PaulFertser | gena2x: before doing bisection i'd advice to cut down the quantity of modules you compile because it contributes to the build (and therefore test) time a lot. |
| 12:21.41 | *** join/#openmoko emacsian (n=ram@122.167.89.156) |
| 12:25.58 | PaulFertser | panicking: i mean how do you know if some process is using FCSE or not and (most important) what amount of context switches happens with with FCSE and what without. |
| 12:26.41 | PaulFertser | panicking: also i'd expect a lot of latency in a typical usage caused by context switches to/from X server and that's an example of process which clearly needs more than 32M of address space. |
| 12:26.42 | panicking | ok, I can do that and add account statiscs to the openmoko kernel |
| 12:26.58 | panicking | android version |
| 12:26.59 | PaulFertser | Weiss: any thoughts on this? |
| 12:28.23 | gena2x | PaulFertser: it's already cut down to fit exactly my machine. I'm traditionally build custom kernel for my home machine for years. |
| 12:28.31 | PaulFertser | panicking: i mean FCSE seems to be quite specialised stuff, beneficial mostly for small hard realtime tasks. TBH i've no idea about amount of address space needed for e.g. enlightment or other apps one is supposed to run on FR. |
| 12:28.37 | *** join/#openmoko azaghal_ (n=azaghal@239.225.178.212.adsl.dyn.beotel.net) |
| 12:29.32 | panicking | I know exaclty |
| 12:29.35 | panicking | what fcse do |
| 12:29.45 | panicking | but maybe can be benefict only android |
| 12:29.47 | PaulFertser | gena2x: same here. It was funny when i needed to recompile my kernel right during a class to be able to use student's portable player as a cardreader because i forgot to enable MULTI_LUN |
| 12:30.36 | PaulFertser | panicking: is the descrition linked from the OM kernel ML accurate enough? If yes, then 95 pid and 32MiB address space limitation seems pretty tough. |
| 12:31.40 | Weiss | PaulFertser: have to go and do all my christmas shopping now :).. but will think about it and get back to you tomorrow.. |
| 12:31.58 | PaulFertser | Weiss: thanks :))) |
| 12:32.02 | PaulFertser | Weiss: good luck |
| 12:33.17 | gena2x | PaulFertser: That's why i said 'home'. Wait? MULTI_LUN? :) |
| 12:33.21 | panicking | PaulFertser, I don't think so |
| 12:33.24 | panicking | why? |
| 12:33.28 | panicking | give me an example |
| 12:33.29 | PaulFertser | panicking: and "best effort" benchmarks didn't look very promising, and as far as i understood that's a necessity to be able to run a non-specialised system. |
| 12:33.49 | PaulFertser | gena2x: yes, when one USB device have several LUNs (internal memory, cardreader, etc). |
| 12:34.03 | panicking | i have about 95 running task |
| 12:34.06 | panicking | maybe more |
| 12:34.08 | PaulFertser | panicking: http://lwn.net/images/conf/rtlws11/papers/proc/p01.pdf |
| 12:34.15 | *** join/#openmoko gunbritt (n=arfmarf@unaffiliated/gunbritt) |
| 12:34.27 | panicking | but how many task do you think that can use |
| 12:34.30 | panicking | it in the fso |
| 12:34.34 | panicking | distribuition |
| 12:34.34 | panicking | ? |
| 12:34.39 | gena2x | panicking: I've read exactly that article |
| 12:34.58 | panicking | What are your conclusion |
| 12:35.02 | gena2x | panicking: And tried to measure context switching overhead on OM. |
| 12:35.06 | panicking | ok |
| 12:35.19 | panicking | so do yoiu have some measure |
| 12:35.20 | PaulFertser | panicking: it's not the question to ask, i think what's important is if most of the context switches are done between the task that can be constraned by 32M address space limit. |
| 12:35.39 | PaulFertser | the tasks |
| 12:35.45 | panicking | We need some measure ok |
| 12:35.51 | panicking | that's is true |
| 12:35.57 | panicking | but for now daily use |
| 12:35.59 | panicking | of the kernel |
| 12:36.05 | gena2x | panicking: I did easy thing - do memcpy in 1 and 2 processes. |
| 12:36.05 | panicking | is a good banckmark |
| 12:36.23 | gena2x | panicking: And compare speed |
| 12:36.34 | PaulFertser | panicking: i mean you want to improve latency by cutting down time of context switching. If most of the switches involve something that is incompatible with FCSE constraints, you're out of luck anyway. |
| 12:36.41 | *** join/#openmoko azaghal__ (n=azaghal@1.225.178.212.adsl.dyn.beotel.net) |
| 12:36.53 | gena2x | panicking: And found out that context switch is negligible, exactly as told in article |
| 12:37.27 | gena2x | panicking: This really matter only if you want to so special stuff like precise timing. |
| 12:37.50 | PaulFertser | panicking: and yes, for hard realtime cache flush time matters. If you can avoid it, great. But users do not need hard realtime, they cannot have it anyway in fact. |
| 12:38.35 | panicking | ok, but if you avoid cache flush |
| 12:38.37 | gena2x | panicking: I'll parse article to find out their estimation... |
| 12:38.41 | DocScrutinizer51 | honestly for a standard system thats futile. 'latency' is not due to taskswitching. rather it is mere computing load to process any event |
| 12:39.15 | panicking | I'm obly trying to increase performace |
| 12:39.23 | panicking | All the point of view are correct |
| 12:39.27 | panicking | but the daily use |
| 12:39.32 | panicking | is the banchmark |
| 12:39.42 | panicking | Numbers are ok |
| 12:39.48 | gena2x | panicking: moment... |
| 12:39.59 | PaulFertser | panicking: it looks like FCSE is not the way to improve user experience, it looks like it should be really neglegible. |
| 12:40.27 | panicking | I must try to check each patch |
| 12:40.37 | panicking | because I have introduce |
| 12:40.39 | panicking | 10 commits |
| 12:40.41 | gena2x | panicking: i wrote several long mails about performance to community maillist. |
| 12:40.44 | panicking | in android kernel |
| 12:40.58 | panicking | I don't read anything |
| 12:40.59 | panicking | sorry |
| 12:41.18 | PaulFertser | It'd interesting to understand why ARM decided to do such a constrained implementation. And it's interesting to read about clever hacks that allow to benefit from it. But it looks like it's not something that can actually help in this particular case. |
| 12:41.18 | panicking | I'm only in kernel mailing list |
| 12:41.48 | gena2x | panicking: they not really straightforward |
| 12:42.09 | panicking | I give frequency scaling 1 month ago |
| 12:42.35 | panicking | ok |
| 12:42.37 | panicking | I can retest it |
| 12:42.43 | panicking | again and measure performance |
| 12:42.55 | panicking | but I don't push on andy-kernel |
| 12:43.01 | panicking | people can try |
| 12:43.04 | panicking | and said |
| 12:43.13 | panicking | It's good |
| 12:43.16 | panicking | or it's no good |
| 12:43.32 | panicking | The same of freq-scaling |
| 12:43.43 | panicking | or buttery mutex recharge |
| 12:43.51 | panicking | or scatter list on mmc |
| 12:44.09 | panicking | the last one are in the linux-2.6.3x |
| 12:44.22 | panicking | the freq-scaling can be reused in 2.6.3x |
| 12:44.29 | panicking | in the part of voltage scaling |
| 12:44.39 | panicking | people can take the code and do a better one |
| 12:44.52 | panicking | I just follow the android branch |
| 12:45.16 | panicking | I only recevie mail about people that said is slow |
| 12:45.18 | *** join/#openmoko pbaxter (n=pbaxter@host150-36-dynamic.117-80-r.retail.telecomitalia.it) |
| 12:45.27 | panicking | so I want to try all |
| 12:46.04 | *** join/#openmoko everslick (n=clemens@212-183-116-2.adsl.highway.telekom.at) |
| 12:46.46 | gena2x | panicking: yes, first reference in article: http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf |
| 12:47.35 | panicking | thanks |
| 12:47.40 | PaulFertser | panicking: (trying all) i'd suggest to those complaining about slowness to get some weed, probably it'd be a reliable way to solve the problem. The device wouldn't become faster but those people will stop caring and will feel happy anyway. |
| 12:47.43 | panicking | I'm going to read the articale |
| 12:48.08 | gena2x | panicking: Oh, can't find exactly place where i read about performance affect. |
| 12:48.53 | gena2x | panicking: But context switch is not problem. |
| 12:49.30 | panicking | But using fcse you avoid cache flushing |
| 12:49.31 | gena2x | panicking: Wait a moment, you mean you have serie of performance patches? |
| 12:49.52 | panicking | I mean that the performace can be related to: |
| 12:50.13 | gena2x | panicking: I propose to decrase HZ. |
| 12:50.17 | panicking | - io-timing that recalculate the refreash rate of gta02 ram |
| 12:50.23 | panicking | - fcse in android |
| 12:50.37 | gena2x | panicking: Why not just do profiling? |
| 12:50.47 | panicking | - avoid unusedn dcache flashing in armv-fault |
| 12:51.11 | panicking | I'm going to eat |
| 12:51.29 | PaulFertser | panicking: enjoy your meal :) |
| 12:51.39 | gena2x | panicking: yes. |
| 12:52.45 | gena2x | panicking: I did some lmbenching, so if you want someone to help testing some performance idea, I'll be glad to participate. |
| 12:53.16 | gena2x | panicking: today or tomorrow. |
| 12:53.53 | gena2x | panicking: after I'll do something with my usb... |
| 12:54.33 | PaulFertser | gena2x: if you have openmoko kernel repository already cloned and no mainline kernel you can cut down on cloning times by using OM repo as a --reference. |
| 12:54.58 | PaulFertser | gena2x: or just add upstream as another remote source to your existing repo. |
| 12:57.08 | gena2x | PaulFertser: hm... no need to track upstream for my usb issue, now I'm just traditionally compiling from tarbz2ball. |
| 12:57.23 | PaulFertser | gena2x: how are you going to do git bisect then? |
| 12:57.40 | gena2x | PaulFertser: Hm. |
| 12:57.56 | gena2x | PaulFertser: yes. |
| 12:58.08 | PaulFertser | gena2x: because finding the particular commit that broked things will really help for the upstream devs to solve the issue. |
| 12:58.49 | PaulFertser | s/for / |
| 13:00.00 | gena2x | PaulFertser: I gues if I'll find particular commit (if it is exist and if it is not my quite stable hw/bios/ bug), then I'll try to hurt them badly with patch ;) |
| 13:00.16 | *** join/#openmoko blan (n=blan@HSI-KBW-085-216-059-158.hsi.kabelbw.de) |
| 13:06.01 | PaulFertser | gena2x: nice plan |
| 13:07.06 | *** join/#openmoko jlmoko (n=jluis@67.Red-83-60-79.dynamicIP.rima-tde.net) |
| 13:12.41 | *** join/#openmoko toi (n=toi@d54C2A96D.access.telenet.be) |
| 13:15.42 | *** join/#openmoko zedstar (n=john@fsf/member/zedstar) |
| 13:27.06 | *** join/#openmoko dos11 (n=dos@aeoh34.neoplus.adsl.tpnet.pl) |
| 13:32.38 | *** join/#openmoko MHazem (n=Satan@41.130.233.158) |
| 13:33.49 | *** join/#openmoko max_posedon (n=max_pose@164-243-252-87-dynamic-pool.gprs.mts.by) |
| 13:38.36 | *** join/#openmoko jlmoko (n=jluis@73.Red-83-37-38.dynamicIP.rima-tde.net) |
| 13:50.10 | *** join/#openmoko Cervajz (n=Cervajz@opensuse/member/Cervajz) |
| 14:10.29 | *** join/#openmoko Fossi (n=fossi@d116019.adsl.hansenet.de) |
| 14:12.05 | *** join/#openmoko Cervajz (n=Cervajz@opensuse/member/Cervajz) |
| 14:17.48 | *** join/#openmoko gena2x (n=gena2x@bsdmn.com) |
| 14:29.16 | *** join/#openmoko Cervajz (n=Cervajz@opensuse/member/Cervajz) |
| 14:40.18 | *** join/#openmoko Cervajz (n=Cervajz@opensuse/member/Cervajz) |
| 14:46.27 | *** join/#openmoko Cervajz (n=Cervajz@opensuse/member/Cervajz) |
| 14:47.18 | *** join/#openmoko emacsian (n=ram@122.167.89.156) |
| 15:03.17 | *** join/#openmoko Fossi1 (n=fossi@e176033022.adsl.alicedsl.de) |
| 15:06.04 | *** join/#openmoko max_posedon1 (n=max_pose@65-243-252-87-dynamic-pool.gprs.mts.by) |
| 15:09.42 | *** join/#openmoko Cervajz (n=Cervajz@opensuse/member/Cervajz) |
| 15:12.05 | *** join/#openmoko beer (n=beer@0x4dd40dcb.adsl.cybercity.dk) |
| 15:14.20 | *** join/#openmoko pespin (n=Sharwin_@40.pool85-50-92.dynamic.orange.es) |
| 15:29.55 | *** join/#openmoko Cervajz1 (n=Cervajz@77.93.201.22) |
| 16:04.24 | panicking | PaulFertser, so what about spurius wakeup of lan |
| 16:04.25 | panicking | ? |
| 16:04.36 | panicking | so why don't change the beahvior of the pin |
| 16:04.40 | panicking | before suspend |
| 16:04.40 | panicking | ? |
| 16:06.35 | lindi- | panicking: wakeup of lan= |
| 16:06.41 | lindi- | s/=/?/ |
| 16:06.55 | PaulFertser | panicking: have you confirmed it ever happened? |
| 16:07.06 | PaulFertser | panicking: because i'm a lazy ass :| |
| 16:07.40 | PaulFertser | lindi-: there's a suspicion with wifi module off one can experience strange wakeups from suspend. |
| 16:07.58 | PaulFertser | lindi-: it looks quite possible, i had a look at the code and schematics. |
| 16:09.08 | PaulFertser | panicking: if you experience any strange wakeup, pretty please report the details! |
| 16:09.23 | panicking | ok |
| 16:09.38 | panicking | For now we only report PMU wakeup reason |
| 16:10.10 | PaulFertser | panicking: it'd be nice to report both, we have everything needed in place already. |
| 16:10.31 | panicking | yes I know |
| 16:10.39 | panicking | but it's a bug in our bug tracker |
| 16:11.05 | PaulFertser | panicking: i thought we all agreed to keep kernel and other low-level bugs at OM bugtracker component "System software"? |
| 16:11.38 | panicking | yes, but this is for sure a android bad design |
| 16:12.03 | PaulFertser | Oh |
| 16:12.10 | PaulFertser | I knew that :P |
| 16:12.18 | panicking | When I find a bug in the kernel |
| 16:12.20 | panicking | I will report |
| 16:12.27 | panicking | I have one but I must investigate |
| 16:12.38 | panicking | panic on resume with usb plug in |
| 16:13.41 | panicking | Paul I always submit patch agaist a problem or panic |
| 16:13.48 | panicking | but I never fill a bug report |
| 16:13.52 | panicking | for my poor english |
| 16:15.47 | mwester | Your english is better than my italian, though. :) |
| 16:19.26 | *** join/#openmoko azaghal_ (n=azaghal@216.228.178.212.adsl.dyn.beotel.net) |
| 16:20.19 | PaulFertser | Same here :) |
| 16:20.26 | *** join/#openmoko Gabrys (n=Gabrys@77-254-66-61.adsl.inetia.pl) |
| 16:20.37 | *** join/#openmoko CVirus (n=Satan@41.153.193.248) |
| 16:20.40 | PaulFertser | panicking: we all appreciate your desire to improve OM kernel, honestly. |
| 16:21.18 | mwester | is happy that somebody is still serious about making Android work on the FR. |
| 16:21.41 | *** join/#openmoko Blastur (n=kebab@86-232-96-87.cust.blixtvik.se) |
| 16:22.20 | panicking | This is a pleusure for me |
| 16:22.27 | panicking | I have contact all the world |
| 16:22.34 | mwester | hehe! Off-topic: I think I found a technical loop-hole that will let me get online whilst I'm imprisoned behind my customer's draconian firewalls. :D |
| 16:22.49 | mwester | So maybe I can become active here again. |
| 16:22.56 | d1b | mwester: lol. |
| 16:23.13 | d1b | mwester: there is a web interface for freenode... |
| 16:24.41 | mwester | d1b, I didn't know that, but I suspect its blocked too -- they block all the so-called "social networking" sites. |
| 16:25.16 | d1b | mwester: yes freenode is a big offender in that category :P |
| 16:25.55 | ndnihil | easy enough to set up your own http->irc gateway, they're likely only blocking by name/ip |
| 16:26.08 | d1b | i would be suprised if they blocked ssh out on port 443. etc. |
| 16:26.25 | mwester | I tried the ssh on 443. |
| 16:26.36 | d1b | oh... proxy? |
| 16:26.38 | mwester | It works for a few minutes, then their firewall kills the connection. |
| 16:27.07 | d1b | interesting. |
| 16:27.24 | *** join/#openmoko Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 16:30.17 | lindi- | panicking: "we only report ..." -- aren't there two resume_reason nodes? |
| 16:30.39 | lindi- | panicking: what is "we" here? "kernel"? |
| 16:32.37 | panicking | can rewrite what I said sorry |
| 16:33.21 | *** join/#openmoko naeg (n=naeg@194.208.239.170) |
| 16:35.26 | *** join/#openmoko nielsle (n=nielsle@1385163669.dhcp.dbnet.dk) |
| 16:36.24 | *** join/#openmoko der-lehmann (n=stefan@188-192-133-169-dynip.superkabel.de) |
| 16:43.15 | *** join/#openmoko jlmoko (n=jluis@107.Red-83-37-39.dynamicIP.rima-tde.net) |
| 16:52.18 | *** join/#openmoko yang (i=yang@sparc.mtveurope.org) |
| 16:58.54 | *** join/#openmoko C7 (n=C7@zux006-058-029.adsl.green.ch) |
| 17:05.40 | *** join/#openmoko emacsian (n=ram@122.167.89.156) |
| 17:06.15 | *** join/#openmoko Gabrys (n=Gabrys@77-254-66-61.adsl.inetia.pl) |
| 17:13.34 | *** join/#openmoko azaghal (n=azaghal@91.148.113.215) |
| 17:18.58 | *** join/#openmoko yang (i=yang@sparc.mtveurope.org) |
| 17:19.02 | *** join/#openmoko PBeck (n=PBeck@HSI-KBW-085-216-075-177.hsi.kabelbw.de) |
| 17:19.20 | PBeck | hi |
| 17:25.10 | *** join/#openmoko playya__ (n=playya@unaffiliated/playya) |
| 17:29.16 | *** join/#openmoko HellDragon (n=jd@modemcable207.134-202-24.mc.videotron.ca) |
| 17:47.21 | *** join/#openmoko thrashold (n=europan@3mhz.net) |
| 18:06.44 | *** join/#openmoko rmoravcik (n=rmoravci@ip-89-102-141-60.karneval.cz) |
| 18:06.57 | *** part/#openmoko rmoravcik (n=rmoravci@ip-89-102-141-60.karneval.cz) |
| 18:10.15 | *** join/#openmoko fsteinel (n=fsteinel@fedora/fsteinel) |
| 18:11.43 | *** join/#openmoko dos1 (n=dos@unaffiliated/dos1) |
| 18:12.07 | *** join/#openmoko MHazem (n=Satan@41.153.51.209) |
| 18:18.58 | *** join/#openmoko thrashold (n=europan@3mhz.net) |
| 18:25.42 | lindi- | larsc: PaulFertser: is there some sysfs node that can tell me if the display is on or off? "xset q" says "monitor is off" but is there some other way to see this? |
| 18:29.58 | larsc | lindi-: /sys/class/lcd/*/lcd_power |
| 18:30.01 | larsc | 0 is on |
| 18:30.05 | larsc | everything else is off |
| 18:31.25 | lindi- | head: cannot open `/sys/class/lcd/*/lcd_power' for reading: No such file or directory |
| 18:31.29 | lindi- | not with andy-tracking |
| 18:32.01 | lindi- | larsc: has this changed recently? |
| 18:32.15 | larsc | hm... yes |
| 18:32.26 | larsc | not recently, but it has changed |
| 18:32.29 | lindi- | larsc: what's the old way? |
| 18:32.58 | lindi- | (also note that I'm using xserver-xorg-video-fbdev in case it matters) |
| 18:33.05 | larsc | wait. have to read the source code |
| 18:34.02 | lindi- | larsc: my suspend script saves the status of display power, turns display off, locks touchscreen and goes to suspend |
| 18:34.20 | lindi- | larsc: the resume hook then reacts to resume-reason and may or may not enable the display |
| 18:34.58 | lindi- | larsc: currently i'm using "xset q" but this does not work if xdm is showing its login prompt and not letting X clients connect |
| 18:35.48 | larsc | lindi-: it's /sys/bus/platform/devices/jbt*/state |
| 18:35.53 | larsc | at least should be |
| 18:36.05 | lindi- | head: cannot open `/sys/bus/platform/devices/jbt*/state' for reading: No such file or directory |
| 18:36.40 | larsc | `ls /sys/bus/platform/devices` ? |
| 18:37.49 | larsc | but you probably want to use the framebuffers status anyway |
| 18:38.01 | larsc | /dev/class/graphics/fb0/blank |
| 18:38.27 | larsc | aeh sys instead of dev... |
| 18:39.14 | lindi- | $ ls /sys/bus/platform/devices|nc paste.dyndns.org 1234 |
| 18:39.14 | lindi- | http://paste.debian.net/54462/ |
| 18:39.51 | lindi- | larsc: '/sys/class/graphics/fb0/blank' is empty file |
| 18:40.05 | larsc | ah... right... the jbt is connected through spi |
| 18:40.34 | larsc | find /sys -name "*jbt*" |
| 18:40.44 | lindi- | only one hit. /sys/bus/spi/drivers/jbt6k74 |
| 18:40.56 | lindi- | has 'bind spi2.0 uevent unbind' |
| 18:41.26 | larsc | then it is /sys/bus/spi/drivers/jbt6k74/spi2.0/state i guess |
| 18:41.29 | lindi- | /sys/bus/spi/drivers/jbt6k74/spi2.0/state ! |
| 18:41.32 | lindi- | works |
| 18:41.33 | lindi- | thanks |
| 18:41.58 | lindi- | thanks |
| 18:42.01 | lindi- | whoops :) |
| 18:42.32 | lindi- | larsc: however "echo normal > /sys/bus/spi/drivers/jbt6k74/spi2.0/state" is not enough to wake the display up. might be X issue |
| 18:42.32 | *** join/#openmoko hannes_s (n=hannes_s@f054143109.adsl.alicedsl.de) |
| 18:43.44 | lindi- | larsc: now http://paste.debian.net/54463/ and the display is indeed blanked |
| 18:43.53 | lindi- | larsc: so "normal" does not mean that display is on |
| 18:44.36 | larsc | but it should |
| 18:44.43 | larsc | iirc |
| 18:45.31 | lindi- | larsc: ok, i guess i need to read X source code |
| 18:48.58 | *** join/#openmoko tsdogs (n=tsdogs@net203-187-146.mclink.it) |
| 18:50.46 | *** join/#openmoko CVirus (n=Satan@41.233.145.178) |
| 19:04.27 | *** join/#openmoko mnt_real (n=sinan@bas12-montrealak-1167974851.dsl.bell.ca) |
| 19:07.05 | *** join/#openmoko Amorphous (i=jan@unaffiliated/amorphous) |
| 19:10.33 | *** join/#openmoko ssam (n=ssam@87.127.117.246) |
| 19:12.05 | *** join/#openmoko CVirus (n=Satan@41.233.145.178) |
| 19:14.18 | *** part/#openmoko der-lehmann (n=stefan@188-192-133-169-dynip.superkabel.de) |
| 19:17.33 | *** join/#openmoko onen|openBmap (n=quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
| 19:45.14 | *** join/#openmoko kirun (n=kirun@78-86-154-194.zone2.bethere.co.uk) |
| 19:46.25 | *** join/#openmoko kkb110 (n=kkb110@pool-173-59-51-194.phlapa.fios.verizon.net) |
| 19:53.49 | *** join/#openmoko Q-Master (n=qmaster@78.111.144.100) |
| 19:58.58 | *** join/#openmoko max_posedon (n=max_pose@65-243-252-87-dynamic-pool.gprs.mts.by) |
| 19:59.37 | *** join/#openmoko max_posedon (n=max_pose@65-243-252-87-dynamic-pool.gprs.mts.by) |
| 20:07.14 | *** join/#openmoko MHazem (n=Satan@41.233.149.26) |
| 20:13.21 | *** join/#openmoko chomwitt (n=chomwitt@ppp-94-66-133-43.home.otenet.gr) |
| 20:33.48 | *** join/#openmoko zing (n=zing@fedora/zing) |
| 20:47.55 | *** join/#openmoko everslick (n=clemens@91-113-120-132.adsl.highway.telekom.at) |
| 20:48.26 | *** join/#openmoko radekp (n=radek@63.120.broadband10.iol.cz) |
| 20:50.01 | *** join/#openmoko azaghal (n=azaghal@91.148.112.194) |
| 20:50.58 | zing | is there some way to make phonelog faster in shr-u? starting is slow and a pause when switching between tabs. |
| 20:57.11 | *** join/#openmoko valos (n=valos@mar92-6-82-227-150-198.fbx.proxad.net) |
| 20:58.53 | *** join/#openmoko _cb^ (n=validuse@AMontsouris-551-1-67-42.w90-24.abo.wanadoo.fr) |
| 21:08.11 | *** join/#openmoko amarsh04 (n=amarsh04@ppp118-210-249-193.lns20.adl6.internode.on.net) |
| 21:11.36 | *** join/#openmoko max_posedon (n=max_pose@2-243-252-87-dynamic-pool.gprs.mts.by) |
| 21:12.13 | *** join/#openmoko f3nix (n=f3nix@gdg19.internetdsl.tpnet.pl) |
| 21:13.22 | *** join/#openmoko chihchun (n=nnnchihc@u7.hlc.edu.tw) |
| 21:39.49 | *** join/#openmoko rmoravcik (n=rmoravci@ip-89-102-141-60.karneval.cz) |
| 21:40.26 | *** part/#openmoko rmoravcik (n=rmoravci@ip-89-102-141-60.karneval.cz) |
| 21:49.17 | PaulFertser | Hey guys, do you have any suggestion how my FR can help me to memorise ~120 words of toki pona? |
| 21:51.14 | ndnihil | toki pona? |
| 21:51.20 | PaulFertser | ndnihil: yep |
| 21:51.28 | ndnihil | whassat? |
| 21:51.35 | PaulFertser | ndnihil: an interesting minimalistic dao-ist language :) |
| 21:51.55 | ndnihil | flashcards? |
| 21:52.06 | PaulFertser | ndnihil: probably, i've no idea, never used anything like that. |
| 21:52.28 | ndnihil | ooh, or run an x86 emu, to run wine, to run rosetta stone |
| 21:53.08 | PaulFertser | ndnihil: do i fucking look like a one who runs proprietary shit unless really forced to? |
| 21:53.08 | ndnihil | I'd start with flashcards |
| 21:53.36 | ndnihil | eh, sometimes I run windows stuff just to shut people up |
| 21:53.40 | ndnihil | "you can't do..." |
| 21:53.43 | ndnihil | "oh yes I can" |
| 21:53.56 | mwester | is a pragmatist. |
| 21:54.07 | mwester | I run whatever it takes on whatever is necessary. |
| 21:54.36 | PaulFertser | mwester: hey |
| 21:54.41 | ndnihil | the software I use on my car is windows only |
| 21:54.46 | ndnihil | works great under wine though |
| 21:55.02 | PaulFertser | mwester: can you share what trick have you found to break through the draconian firewalls? |
| 21:55.03 | mwester | There's already to much religious fanaticism in the world, IMO there's no good to come of making my hobby into a religion ;) |
| 21:55.22 | mwester | You won't like it PaulFertser -- it involves proprietary software! |
| 21:55.37 | PaulFertser | mwester: i'd still like to hear about it |
| 21:56.23 | ndnihil | stunnel not doing it? |
| 21:56.38 | *** join/#openmoko der-lehmann (n=stefan@188-192-133-169-dynip.superkabel.de) |
| 21:56.38 | PaulFertser | mwester: and btw i want to congratulate you with finding it, i hope it'll make your working experience more enjoyable :) |
| 21:57.14 | mwester | It's really simple, as most solutions ultimately end up being -- I created a Fedora virtual machine, and attach a USB-based wifi dongle to it. I cloned the MAC address of a vendor device that's allowed on the vendor/guest WIFI lan... |
| 21:57.46 | mwester | So now I have a connection that is free of the draconian internal network. |
| 21:58.11 | mwester | And as a bonus, I have a usable Linux environment on the company-owned laptop. |
| 21:59.08 | PaulFertser | mwester: is the proprietary software you used VirtualBox? |
| 21:59.23 | mwester | No - it's VMware Workstation. |
| 21:59.56 | mwester | The latest version (7.0) finally got the USB stuff working to where the wifi device actually connects. |
| 22:00.05 | ndnihil | gave up on being 100% open |
| 22:00.18 | ndnihil | it's nice in theory, but not practical |
| 22:00.20 | PaulFertser | gave up on being 100% saint |
| 22:00.35 | mwester | set a goal to be 0% saint. |
| 22:00.36 | PaulFertser | But it'd be still nice to try ;) |
| 22:00.41 | mwester | I like attainable goals. |
| 22:00.58 | ndnihil | it is nice to try, but you'll always have to compromise somewhere |
| 22:02.22 | PaulFertser | fails to set any goals for his life, it goes its own way regardless of what i dream of. |
| 22:03.54 | mwester | But I've got to say that some of the desktop Linux distros have come a very very long way in the past couple of years -- it's more practical now to "live" in Linux in a corporate env than ever before. One of my co-workers (with a more "enlightended" customer) has inverted my solution -- he runs Fedora, with a VMware windows env for those few apps that still need windows. |
| 22:04.01 | PaulFertser | mwester: (proprietary software) btw, one local company producing various measuring equipment gave me the source for the windows driver of their PCI DAQ board when i requested for more information to be able to write a driver. That's an attitude i like. |
| 22:04.26 | ndnihil | that's rare |
| 22:05.39 | PaulFertser | Not that it helped me to manage to figure what's wrong with my basic driver but i still has hope. |
| 22:05.42 | mwester | I'm liking those companies that release hardware with an open linux driver to begin with, rather than waiting for a dev to ask for docs to write a linux driver. I think the days of the "all you need is a windows reference driver" are fading. |
| 22:06.03 | Wonka | mwester: my orkplace runs xen-domUs. some clients want virtualized windows servers because they don't trust linux to be stable enough... now guess what the dom0s run? |
| 22:06.19 | PaulFertser | Wonka: LOL |
| 22:06.29 | ndnihil | heh |
| 22:06.34 | ndnihil | *hearts* xen |
| 22:06.39 | mwester | Wonka, that's hilarious! Do any of the managers understand that?! :D |
| 22:07.00 | Wonka | the clients don't, obviously |
| 22:07.14 | PaulFertser | mwester: intel released their wimax solution with a good driver, that's even accepted mainline. |
| 22:07.21 | Wonka | our managers do, they're all from the techie world |
| 22:07.26 | mwester | Yeah, and I suppose it wouldn't be good for business to "educate" the clients, huh? |
| 22:08.00 | PaulFertser | mwester: too bad it required proprietary suppliant to be actually useful :) |
| 22:08.15 | Wonka | one could still argue that the linux dom0 only does limited stuff and does not run the real applications, so is less likely to be unstable anyway |
| 22:09.34 | ndnihil | up 231 days |
| 22:09.48 | ndnihil | ^one of my dom0's, and it's domU's have the same |
| 22:09.48 | PaulFertser | mwester: also intel released a free X driver for their video chips but it (i think still) requires proprietary vbios for modesetting. |
| 22:10.05 | ndnihil | and it was only rebooted because of a power outage in the building |
| 22:10.46 | lindi- | Wonka: aren't the linux dom0 patches still not even in mainline? |
| 22:14.05 | PaulFertser | lindi-: i think mainline decided to go away from xen |
| 22:18.27 | Wonka | lindi-: I am not really involved there. |
| 22:32.22 | PaulFertser | ndnihil: from all popular flashcard programs apt-get install granule seems to fit my debian system best as it doesn't depend on Qt :) |
| 22:32.29 | *** join/#openmoko kkb110 (n=kkb110@pool-173-59-51-194.phlapa.fios.verizon.net) |
| 22:41.47 | *** join/#openmoko raster (n=raster@enlightenment/developer/raster) |
| 22:45.46 | *** join/#openmoko Gabrys (n=Gabrys@77-254-66-61.adsl.inetia.pl) |
| 22:48.28 | *** join/#openmoko rhaeder (n=rhaeder@188.109.244.80) |
| 22:51.23 | *** join/#openmoko PaulFert` (n=PaulFert@mail.nixl.net) |
| 22:55.51 | *** join/#openmoko _Fox_Muldr (i=quakeman@f051176137.adsl.alicedsl.de) |
| 23:06.31 | *** join/#openmoko md2k7 (n=david@h081217039232.dyn.cm.kabsi.at) |
| 23:26.42 | *** join/#openmoko pooze (n=imo@82.80-202-92.nextgentel.com) |
| 23:29.26 | pooze | I just upgraded my SHR and got a collection of errors. |
| 23:29.46 | pooze | it seems a package called 'libvorbis0' wants to install a couple of files provided by 'libvorbis' |
| 23:29.56 | pooze | seems like the package has been renamed or something. |
| 23:30.08 | pooze | anybody has a clue how to fix it? |
| 23:30.39 | Heinervdm | pooze: just remove the old package |
| 23:31.00 | pooze | heinervdm: ok, thanks. |
| 23:31.14 | pooze | but it also seems my upgrade wants to install openssh, which conflicts with dropbear. |
| 23:31.25 | pooze | should I also remove dropbear and let openssh be installed? |
| 23:31.39 | Heinervdm | you can |
| 23:31.48 | pooze | I'm kind of using dropbear at the moment. |
| 23:31.56 | Heinervdm | it seems you haven't upgraded for a long time |
| 23:32.38 | Heinervdm | for openssh you have to set a root password |
| 23:33.15 | pooze | heinervdm: that's true, my task-base is upgrading from 1.0-r85.4 to 1.0-r87.4, I think it was around 1st of December. |
| 23:33.28 | pooze | heinervdm: I always have a root password. |
| 23:34.03 | Heinervdm | then you wont have a problem with openssh |
| 23:34.45 | pooze | the phone hung completely when upgrading, and after rebooting it the hard way (battery removal), it didn't start X. So I would like my current upgrade to be successful so I can start X and do the dropbear -> openssh switch from the terminal. |
| 23:35.21 | pooze | since ssh is my only way of interacting with the phone right now. |
| 23:35.54 | Heinervdm | then just ignore openssh for now |
| 23:37.05 | pooze | ok, I'll see if I can do that. |
| 23:37.18 | pooze | just removed 'apm' as well, since 'fso-apm' conflicted with it. |
| 23:37.38 | Heinervdm | everything else will be upgraded |
| 23:37.43 | Heinervdm | thats right |
| 23:38.01 | Heinervdm | also remove shr-today |
| 23:38.45 | pooze | ops.. "ERROR: Package fso-apm (parent fso-apm) is not available from any configured src." |
| 23:38.54 | pooze | what does that error mean? |
| 23:39.23 | pooze | "installing fso-apm ( ... ) to root..." |
| 23:39.33 | pooze | followed by "cannot find package fso-apm." |
| 23:41.17 | Heinervdm | fso-apm is there... |
| 23:41.34 | Heinervdm | its in Packages and the package exists |
| 23:41.34 | pooze | it is.. it can even find the version number for it. |
| 23:41.59 | pooze | which is why it's strange it later says it can't find it. |
| 23:42.18 | pooze | but I didn't get the "parent fso-apm" thing. |
| 23:42.44 | Heinervdm | hmm, don't know |
| 23:43.46 | pooze | ah, perhaps I shouldn't install fso-apm directly, but through upgrading task-base-apm? |
| 23:43.54 | *** join/#openmoko HellDragon (n=jd@modemcable207.134-202-24.mc.videotron.ca) |
| 23:45.08 | Heinervdm | don't know, it should work |
| 23:45.45 | Heinervdm | but i have to go now, i need some sleep :) |
| 23:45.54 | pooze | ok, thanks for the help so far anyway. :) |
| 23:46.17 | *** join/#openmoko HellDragon (n=jd@modemcable207.134-202-24.mc.videotron.ca) |
| 23:49.18 | pooze | anybody else has a clue on this one? |
| 23:49.22 | pooze | root@om-gta02 ~ $ opkg install task-base-apm |
| 23:49.22 | pooze | Installing task-base-apm (1.0-r87.4) to root... |
| 23:49.22 | pooze | Downloading http://build.shr-project.org/shr-unstable/ipk//om-gta02/task-base-apm_1.0-r87.4_om-gta02.ipk |
| 23:49.23 | pooze | Installing fso-apm (1:2.0.0+gitr800+1dcf546fb0423930f938129a51f538874c172226-r0.4) to root... |
| 23:49.23 | pooze | Collected errors: |
| 23:49.23 | pooze | <PROTECTED> |
| 23:49.25 | pooze | <PROTECTED> |
| 23:49.27 | pooze | <PROTECTED> |
| 23:49.41 | pooze | I did an 'opkg update' of course. |