**** BEGIN LOGGING AT Fri Oct 09 03:00:00 2009
Oct 09 04:34:56 <PaulFertser> ndnihil: it was me.
Oct 09 04:35:31 <PaulFertser> ndnihil: it's not bfs fix, it's just a tweak found by guys who were researching why bfs performed better than cfs on some workloads.
Oct 09 04:46:24 <slaxxer> Doom Milestone II ready?
Oct 09 05:59:32 <PaulFertser> Inability to turn my FR on without a lab PSU is hm... unfortunate :-/
Oct 09 06:01:57 <raster> PaulFertser: isnt is awesome.
Oct 09 06:01:58 <raster> :)
Oct 09 06:03:58 <PaulFertser> raster: i'll change Qi to set usb current limit to 400 by default. It can't harm anything anyway.
Oct 09 06:04:31 <raster> makes sense
Oct 09 06:04:58 <raster> normally what u'd want is the soc (here the arm 2442 tto sum up initially in its lowers clockrate (eg lest sate thats 50mhz)
Oct 09 06:05:40 <raster> so that it draws very little current and can probably at least start on 100ma@5v (500mw)
Oct 09 06:05:47 <raster> for the whole system that is - not just the soc
Oct 09 06:05:56 <PaulFertser> raster: Qi does that already and boots the kernel in 100mA envelope. It's the kernel turning on everything else (first of all, BL) that's ruining the fun.
Oct 09 06:06:03 <raster> at least that'd let up negotiate 500ma
Oct 09 06:06:19 <raster> PaulFertser:  thats totally not happy
Oct 09 06:06:33 <raster> definitely keep everything off (and hope that things start in their off start when power comes up)
Oct 09 06:06:37 <raster> until u have 500ma negotiated
Oct 09 06:07:06 <raster> if u cant run the system on 500ma@5v (2.5watts) enough to then charge the battery. you have a crap piece of hw :)
Oct 09 06:07:58 <PaulFertser> The kernel is the problem currently. But we do not have enough reasons to care that much about violating 100mA anyway. I think it's not a problem if some user uses unpowered usb hub and other devices are on and he decides to start his FR with a flat battery and the motheboard cuts off the whole hub. Not a real issue anyway. And with a quick fix to Qi to draw 400mA he'll happily boot his FR no matter what (if he doesn't use that bogus ill scenario wi
Oct 09 06:08:00 * raster goes back to gles
Oct 09 06:08:04 <PaulFertser> ... a hub).
Oct 09 06:08:47 <raster> sure
Oct 09 06:08:53 <raster> but u need to negotiate to 500ma
Oct 09 06:09:00 <raster> i believe 500ma is usb's max.. right?
Oct 09 06:09:17 <raster> wondering why u are doing 400
Oct 09 06:10:56 <PaulFertser> raster: to let the user use an unpowered usb hub without any other heavy consumers. And the kernel will negotiate on current, just a bit later, after it actually boots :) I can't see it doing any harm that way.
Oct 09 06:11:16 <raster> it shouldnt
Oct 09 06:11:21 <raster> the problem is when u dont get 500ma
Oct 09 06:11:29 <PaulFertser> And DocScrutinizer-8 agrees. He's actually always pushing for that.
Oct 09 06:11:30 <raster> u arent guaranteed to get it
Oct 09 06:11:42 <PaulFertser> NP, the user will just switch to the other port then.
Oct 09 06:11:52 <raster> sure
Oct 09 06:12:02 <raster> the problem is when u boot, ask for 500m
Oct 09 06:12:17 <PaulFertser> And currently i just needed to actually take a lab PSU, hold the wires with great care, jump start etc. Highly suboptimal.
Oct 09 06:12:24 <raster> then just blindly turn stuff on anyway so u turn off as u just dont get the current u asked for
Oct 09 06:12:50 <raster> or u turn the stuff on before asking for 500m just assuming u are given 500ma
Oct 09 06:15:10 <PaulFertser> Those hypothetical problems (host refuses to negotiate on 500mA) are neglegible comparing to problems with booting i experienced today :)
Oct 09 06:15:28 <raster> sure
Oct 09 06:15:34 <raster> but thats just somethng to handle
Oct 09 06:15:49 <raster> ie ask for 500ma - dont get it - blink eld red 10 times then power off
Oct 09 06:16:09 <raster> and of course negotiate for it before u turn anything else on
Oct 09 07:16:06 <beer> ?
Oct 09 07:16:39 <Kamping_Kaiser> mmm. beer.
Oct 09 07:41:19 <DocScrutinizer-8> raster: I'd probably hate this, as it renders all non-om wallchargers unusable
Oct 09 07:42:04 <raster> ???
Oct 09 07:42:32 <raster> you shoukldt need a wallcharger if u can start on 100ma
Oct 09 07:42:41 <DocScrutinizer-8> [08:15] <raster> ie ask for 500ma - dont get it - blink eld red 10 times then power off
Oct 09 07:43:09 <raster> just plug into a real pc
Oct 09 07:43:24 <raster> i guess if you ONLY have a dumb wallcharger and nothing else
Oct 09 07:43:36 <raster> but really.. how many people want more wallwarts? :)
Oct 09 07:43:49 <DocScrutinizer-8> WTF? do you suggest I buy a "real pc" for charging FR next my bed?
Oct 09 07:44:09 <raster> you have one :)
Oct 09 07:44:19 <raster> u dont need to buy
Oct 09 07:44:31 <DocScrutinizer-8> no, I don't have
Oct 09 07:44:47 <DocScrutinizer-8> a PC next to where FR sits usually
Oct 09 07:45:05 <DocScrutinizer-8> and I don't see the problem anyway
Oct 09 07:45:36 <DocScrutinizer-8> FR is the fsckng *only* device on gods wide earth to care about that non-issue
Oct 09 07:47:14 <raster> wait - last i checked u had a laptop?
Oct 09 07:47:58 <raster> it'd be nice if there was a way to measure the current supplied
Oct 09 07:48:01 <DocScrutinizer-8> (actually it's NOT, as with all the meddling and messing around in uBoot and kernel FR happily takes 500mA from beginning now)
Oct 09 07:49:31 <DocScrutinizer-8> (as do all the other devices I know about: external drives, ubb-mugwarmers, random foo)
Oct 09 07:50:36 <raster> as best i know u are not guaranteed to be given 500ma until u negotiate for it and get an ok
Oct 09 07:51:09 <DocScrutinizer-8> external usb-drives (hd) sometimes using up to 2.5A on power-up. they come with a y-cable then to split the surge to two usb-ports of PC
Oct 09 07:51:39 <DocScrutinizer-8> that's correct
Oct 09 07:51:46 <DocScrutinizer-8> but so what?
Oct 09 07:52:08 <Wonka> you are not even allowed(!) to draw more than 100mA before having successfully(!) negotiated for it, afaik
Oct 09 07:52:17 <DocScrutinizer-8> premature suicide in fear of potential death?
Oct 09 07:52:41 <DocScrutinizer-8> Wonka: also correct. alas nobody cares
Oct 09 07:53:29 <Wonka> for the wallwart, there's the ID pin
Oct 09 07:53:43 <Wonka> for dumb chargers, there's the option to force 500mA
Oct 09 07:53:53 <DocScrutinizer-8> no, for the OM wallwart there is
Oct 09 07:53:59 <Wonka> but without being forced, IMO it should act standards compliant
Oct 09 07:54:13 <Wonka> ok, I meant the OM wallwart
Oct 09 07:55:11 <DocScrutinizer-8> Wonka: so you're free to continue effort to make that happen for €974 bl & kernel
Oct 09 07:55:16 <Wonka> would be nice, btw, if one could force other currents too... i'd like 700mA because I have a charger with "700mA" on the label
Oct 09 07:55:39 <DocScrutinizer-8> s/€974/YOUR/
Oct 09 07:55:40 <apt> DocScrutinizer-8 meant: Wonka: so you're free to continue effort to make that happen for YOUR bl & kernel
Oct 09 07:56:24 <Wonka> "bl"?
Oct 09 07:56:26 <Wonka> backlight?
Oct 09 07:56:35 <DocScrutinizer-8> bootloader
Oct 09 07:57:13 <Wonka> ah
Oct 09 07:58:17 <Wonka> most times when I boot my FR, I don't need a charger or I have the OM wallwart ready - so it's quite a non-issue practically
Oct 09 08:00:38 <PaulFertser> DocScrutinizer-8: i'm not sure current kernel draws 500mA no matter what. At least i couldn't boot on just usb.
Oct 09 08:01:17 <DocScrutinizer-8> Wonka: as there's so many devices that simply don't care about enum at all (wallwarts, usb-fans, external drives) it's actually a non-issue. But not for FR but for all the usb-hosts that simply must not break on any device drawing 500
Oct 09 08:01:54 <Wonka> if I were a HW manufacturer, I'd put out devices that cut the 5V for 5s for overcurrents... :>
Oct 09 08:02:28 <DocScrutinizer-8> if you were, you're going bankrupt
Oct 09 08:03:58 <Wonka> depends on the type of device ;)
Oct 09 08:04:12 <DocScrutinizer-8> the expensive host devices detect overcurrent, the less expensive only do a fixed current limiting on 500mA, the cheap ones burn on 1A. no device does adjustable usb-current-limit
Oct 09 08:04:49 <DocScrutinizer-8> a rogue nasty OS might decide to do what you suggested
Oct 09 08:06:48 <DocScrutinizer-8> but I don't know of a single device that actually takes harm in a >100mA supply on it's usb-host
Oct 09 08:08:14 <PaulFertser> DocScrutinizer-8: and if it does it means that device is not compliant because there shouldn't be any harm for shorting anything to anything for any time.
Oct 09 08:08:24 <DocScrutinizer-8> and your mentioned unability to boot from USB is a really braindamaged can of bugs in uBoot, which does everything wrong on detecting low bat
Oct 09 08:08:41 <DocScrutinizer-8> PaulFertser: exactly
Oct 09 08:09:39 <Defiant-> DocScrutinizer-8: so booting from USB works with Qi?
Oct 09 08:09:54 <DocScrutinizer-8> (bugs in uboot) not NOR uboot though
Oct 09 08:10:19 <DocScrutinizer-8> Defiant-: boot from usb works with NOR uboot usually
Oct 09 08:10:43 <Defiant-> DocScrutinizer-8: k
Oct 09 08:13:16 <PaulFertser> DocScrutinizer-8: booting from usb works with Qi but the device dies when the kernel turns on some devices (backlight, change to 400MHz etc)
Oct 09 08:14:02 <DocScrutinizer-8> hmm, that's bad behaviour of kernel then
Oct 09 08:15:18 <DocScrutinizer-8> if Qi set usb-curlim to 100 and manages to boot to kernel, then kernel could *know* it's suicide to do that
Oct 09 08:15:22 <PaulFertser> DocScrutinizer-8: indeed but i fail to see why doesn't anybody with a debug board solves it. Probably because nobody cares and that's why i agree we should just modify Qi to let the kernel boot.
Oct 09 08:17:31 <DocScrutinizer-8> oh, well. *old* uboot works great wrt to booting for me. "new" uboot is fubar and instead of charging bat even depletes bat further when it finds bat-V is "too low to boot"
Oct 09 08:18:07 <DocScrutinizer-8> I never used Qi so I have no opinion on that in any way
Oct 09 08:19:43 <DocScrutinizer-8> but obviously it's not *that* simple to get *everything* right in usb-enum's backyard. When ever werner messed it up fubar
Oct 09 08:21:20 <DocScrutinizer-8> s/ever/even
Oct 09 08:35:12 <DocScrutinizer-8> PaulFertser: nota bene uboot and qi both can do anything only *after* device managed to "boot". So I don't see any use in further messing around with enum in bl, rather kernel should do device crank-up sequence in a sensible sequence and manner
Oct 09 08:41:08 <PaulFertser> DocScrutinizer-8: i guess if we just allow ~400mA by initializing pcf in Qi we'll get to the enumerating without issues.
Oct 09 08:41:42 <DocScrutinizer-8> very usually yes we should get there
Oct 09 08:42:45 <DocScrutinizer-8> and that's actually the behaviour I suggest for most simple and as sane as it gets boot method
Oct 09 08:46:53 <DocScrutinizer-8> PaulFertser: btw, I just start to think about whether modem-enable should probe for Vbat > 3V5, as otherwise the modems behaviour isn't determined
Oct 09 08:48:30 <PaulFertser> DocScrutinizer-8: well... i'm not sure code complication worth the benefit. Especially given sometimes voltage readings can be unavailable.
Oct 09 08:48:52 <DocScrutinizer-8> hmm, agree
Oct 09 08:49:43 <andi> I often was confused because the modem did not work because of low battery
Oct 09 08:50:32 <andi> Now I know I have to power-cycle it
Oct 09 08:51:47 <andi> that is not very userfriendly
Oct 09 08:51:49 <DocScrutinizer-8> andi: yup. modem shuts down on low batvolt, though kernel(sysfs) thinks it's up and running
Oct 09 08:52:59 <DocScrutinizer-8> I talked with mickey|sofa about some kinda "keep alive check" in FSOs modem driver to detect modem shutdown
Oct 09 08:53:51 <DocScrutinizer-8> he liked the idea iirc
Oct 09 08:54:16 * lindi- has had a gsm watchdog for ages now anyway ;-)
Oct 09 08:55:55 <DocScrutinizer-8> lindi-: I know you have a lot of basically highly useful cool stuff in your system. Alas it's mostly not implemented as nicely integrated to system/framework as it should be
Oct 09 12:26:21 <freerunnerlive> hi i need some modules
Oct 09 12:26:28 <freerunnerlive> i have qtmoko v13 
Oct 09 12:26:42 <freerunnerlive> this kernel Linux neo 2.6.29-GTA02_qtmoko-v13-mokodev
Oct 09 12:26:55 <freerunnerlive> and this sources  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
Oct 09 12:27:18 <freerunnerlive> at the end i have a failture : invalid modules format
Oct 09 12:28:17 <freerunnerlive> i need videodev.ko v4l2-common.ko  v4l1-compat.ko uvcvideo.ko
Oct 09 14:21:52 <PaulFertser_> max_posedon: i do not think badblocks in NAND can happen because of falls ;)
Oct 09 15:05:53 <max_posedon> even from 2m high?(
Oct 09 15:09:39 <PBeck> hi
Oct 09 15:49:34 <DocScrutinizer> max_posedon: nah, badblocks for sure not. But corrupted fs easily, if ther was a write action in progress the moment your bat popped out
Oct 09 16:59:46 <xperia> ~seen leviathan
Oct 09 16:59:52 <apt> leviathan is currently on #htc-linux. Has said a total of 16 messages. Is idling for 29s, last said: 'hmm'.
Oct 09 17:21:49 <pieterc> Is there an october image of SHR around?
Oct 09 17:27:33 <pieterc> should i flash the 6 september image?
Oct 09 17:29:40 <pieterc> mrmoku images okay?
Oct 09 17:33:10 <slaxxer> 090609 works
Oct 09 17:33:24 <slaxxer> shr
Oct 09 17:35:35 <pieterc> I like to live on the edge, so i'm flashing yesterday's images of mrmoku ;)
Oct 09 17:35:54 <ndnihil> mrmoku?
Oct 09 17:35:56 <ndnihil> whassat?
Oct 09 17:36:18 <pieterc> mrmoku is mrmoku ;)
Oct 09 17:36:20 <pieterc> http://build.shr-project.org/tests/mrmoku/unstable/images/om-gta02/
Oct 09 17:36:33 <ndnihil> ah still shr images
Oct 09 17:36:39 <pieterc> yep
Oct 09 17:44:28 <slaxxer> when did those show up??
Oct 09 17:56:36 <pieterc> no idea
Oct 09 17:56:46 <pieterc> I'm testing one and so far I like it
Oct 09 17:57:08 <pieterc> It actually is pretty fast
Oct 09 19:07:53 <skamster> hello there
Oct 09 19:08:20 <skamster> is there a repo for the new versions of fso and the shr-things?
Oct 09 19:09:34 <skamster> because the normal one doesn't work.. and i'm i don't belive that it do next time.. :/
Oct 09 20:40:43 <CIA-44> freesmartphone.org: 03seba.dos1 07dos/opimd-tracking * r03d45469bc1c 10framework/framework/subsystems/opimd/helpers.py: opimd: helpers: little cosmetic fix
**** ENDING LOGGING AT Sat Oct 10 02:59:56 2009