| twb | lilstevie: any idea what the trick is to make bluetooth work? Specifically, http://paste.ubuntu.com/769608/ | 01:14 |
|---|---|---|
| lilstevie | twb: 1) make sure the bluetooth hcd is in /lib/firmware | 01:17 |
| lilstevie | 2) service bsp-tf101 start | 01:17 |
| lilstevie | 3) cross your fingers and all extremities that it works properly | 01:17 |
| lilstevie | bluetooth is a pita | 01:17 |
| lilstevie | and does not always work | 01:17 |
| twb | :-( | 01:18 |
| lilstevie | oh main thing, make sure BCM4329.hcd is bcm4329.hcd | 01:18 |
| lilstevie | reminant of the old method capitalizes it, when it needs to be lower case | 01:19 |
| twb | Did that already | 01:19 |
| lilstevie | ok | 01:19 |
| lilstevie | check if brcm_patchram_plus is running | 01:19 |
| twb | bsp-tf101 is configured to start by default, so why wouldn't it have worked already? | 01:19 |
| twb | Yes, it's running | 01:19 |
| lilstevie | just making sure | 01:20 |
| lilstevie | now do you have x? | 01:20 |
| twb | atm yes | 01:20 |
| twb | but started from xinit, not a dm | 01:20 |
| lilstevie | ok look at the bluetooth icon in the systray | 01:20 |
| twb | ha ha, systray | 01:20 |
| twb | I said I have X not unity :P | 01:21 |
| lilstevie | haha :p | 01:21 |
| twb | mainly I started X to get keyboard repeat, but it's being funny there too -- which is why I'm trying to get my bt kb working | 01:21 |
| lilstevie | ok | 01:22 |
| twb | Where "funny" means e.g. I hold Ctrl+p, and it types ^P over and over -- and keeps typing it if I release p, until I also release Ctrl | 01:22 |
| lilstevie | well I know I can see the bt stuff from the gnome bluetooth manager | 01:22 |
| lilstevie | but I also can from hcitool | 01:23 |
| lilstevie | have you rebooted since fixing up the hcd? | 01:23 |
| twb | I'll try restarting that bsp thing | 01:23 |
| twb | Yeah, definitely restarted since | 01:23 |
| lilstevie | that won't really help :/ | 01:23 |
| lilstevie | brcm_patchram is a pita | 01:23 |
| lilstevie | and I haven't fully set the bsp package to handle restarting | 01:23 |
| lilstevie | stop the bsp package | 01:24 |
| twb | how? | 01:24 |
| lilstevie | make sure brcm_patchram is killed | 01:24 |
| twb | Righto | 01:24 |
| lilstevie | service bsp-tf101 stop? | 01:24 |
| twb | You know I could help yo make that an upstart job if you prefer | 01:24 |
| lilstevie | it is brcm_patchram actually that is the problem | 01:24 |
| lilstevie | brcm_patchram sometimes needs to be forcefully killed | 01:25 |
| lilstevie | in fact those times when you shutdown the system, and it never seems to turn off, but just sit there.... thats brcm_patchram | 01:25 |
| lilstevie | :p | 01:25 |
| twb | Oh I wondered about that | 01:25 |
| twb | When it sits as "killing all processes" ? | 01:26 |
| lilstevie | yep | 01:26 |
| twb | LAME | 01:26 |
| lilstevie | thats it refusing to die | 01:26 |
| lilstevie | now, once you have successfully killed the process, hopefully a kill -9 will do it | 01:26 |
| lilstevie | you need to rfkill block it | 01:27 |
| lilstevie | otherwise you can't reclaim the interface | 01:27 |
| twb | Why not put the rfkill in the sto rule? | 01:27 |
| lilstevie | thats fine, but I am not comfortable doing a -9 kill in the stop rule | 01:28 |
| twb | OK, then I will do it locally :P | 01:28 |
| lilstevie | and the rfkill must be done after the kill | 01:28 |
| twb | after the kill -15 ? | 01:28 |
| lilstevie | yes | 01:28 |
| twb | That's fucked up | 01:28 |
| lilstevie | otherwise the iface goes into some crazy land of fail | 01:28 |
| TheMuso | Is this under the 2.6.38 kernel or the android derived kernel? | 01:29 |
| lilstevie | both | 01:30 |
| lilstevie | 2.6.38 is a little more forgiving | 01:30 |
| lilstevie | but brcm_patchram trashes the interface on being killed | 01:30 |
| lilstevie | I would like to redesign it to me more daemonish | 01:30 |
| lilstevie | :p | 01:31 |
| lilstevie | like something that will accept being asked to release | 01:31 |
| lilstevie | rather than being shot in the head | 01:31 |
| lilstevie | cause the problem is that you shoot brcm_patchram in the head, and leave its initialized interface behind | 01:31 |
| lilstevie | brcm_patchram will not reinitialize an interface | 01:32 |
| lilstevie | and an initialized interface will not be reinitialized again | 01:32 |
| twb | So this is YOUR code? | 01:32 |
| lilstevie | no | 01:32 |
| twb | Not some crazy closed thing? | 01:32 |
| lilstevie | this is broadcomm code | 01:32 |
| lilstevie | but open broadcomm code | 01:33 |
| twb | Ah, O | 01:33 |
| twb | OK | 01:33 |
| twb | Goddamn keyboard | 01:33 |
| lilstevie | anyway, after killing brcm_patchram softblocking, and unblocking cause the interface to reset because brcm_patchram wasn't there to hold its hand | 01:34 |
| twb | btw is rfill supposed to be unblocked when bsp thingo starts? | 01:34 |
| lilstevie | should be yes | 01:34 |
| twb | OK that is probably why it isn't working for me | 01:34 |
| twb | Because whenever I look it's soft blocked, probably because it does that at boot | 01:34 |
| lilstevie | hm | 01:34 |
| lilstevie | maybe I put the old version of the init.d script in there then | 01:35 |
| lilstevie | it should unblock it on boot | 01:35 |
| lilstevie | but the old version didn't | 01:35 |
| twb | I've trashd your version now so I can't check :P | 01:35 |
| lilstevie | oh lol | 01:35 |
| lilstevie | well anyway, brcm_patchram requires the interface be unblocked when it is invoked | 01:36 |
| twb | Heh, now I have a dozen brcm_patchram_plus's running | 01:38 |
| twb | I might also just patch the halt script to ignore if that proc is still running... | 01:39 |
| === twb` is now known as twb | ||
| twb | lilstevie: after reboot hcitool scan is working | 02:23 |
| twb | lilstevie: I think you shipped the unblock-less version of the script | 02:23 |
| lilstevie | oops | 02:24 |
| lilstevie | sorry :p | 02:24 |
| lilstevie | just so you know, the bluetooth is still very hit and miss | 02:25 |
| twb | Understood | 02:26 |
| lilstevie | just don't get your hopes up | 02:26 |
| lilstevie | I have successfully synced my mouse to the bluetooth a grand total of once | 02:27 |
| lilstevie | and used it that is | 02:27 |
| lilstevie | I have synced the mouse many times | 02:27 |
| lilstevie | only once was it usable | 02:28 |
| twb | I'm gonna get a fucked up back if I can't get a kb workin | 02:28 |
| twb | Still have my old USB one, might use that | 02:28 |
| lilstevie | heh | 02:29 |
| twb | s/fucked up/more fucked up/ | 02:29 |
| lilstevie | lol | 02:31 |
| twb | wow bluetooth crashed | 02:41 |
| twb | http://paste.ubuntu.com/769642/ | 02:41 |
| twb | http://paste.ubuntu.com/769644/ is the init script I'm using -- lilstevie do you think I should be blocking/unblocking only one of the two bt devices? | 02:43 |
| lilstevie | shouldn't make a difference | 02:45 |
| desrt | any word yet about the transformer prime? | 02:46 |
| lilstevie | no | 02:46 |
| lilstevie | it is not looking good though | 02:47 |
| desrt | bootloader locked down? | 02:47 |
| lilstevie | http://androidroot.mobi/2011/12/13/thoughts-on-android-tablet-security/ | 02:47 |
| lilstevie | well we haven't had one in our hands yet | 02:47 |
| lilstevie | but the dlupdate shows that this time even the blobs are signed | 02:47 |
| desrt | lame. | 02:49 |
| desrt | have to wait for a better tegra3 system to come along, i guess | 02:49 |
| twb | bluetoothd[4662]: input/server.c:connect_event_cb() Incoming connection from E8:06:88:52:C7:74 on PSM 17 | 02:51 |
| twb | bluetoothd[4662]: input/server.c:connect_event_cb() Incoming connection from E8:06:88:52:C7:74 on PSM 19 | 02:51 |
| twb | *** glibc detected *** bluetoothd: free(): invalid next size (fast): 0x2a7e6eb0 *** | 02:51 |
| twb | So, uh, bluetoothd is doing a bad free() in oneiric? | 02:51 |
| lilstevie | hm | 02:54 |
| twb | FWIW, keyboard repeat on tty is fine on an external USB keyboard | 02:59 |
| twb | So it must be something in the kb controller | 02:59 |
| twb | Feels weird to have a full-width keyboard for the first time in years | 03:00 |
| lilstevie | heh I'd believe it | 03:00 |
| lilstevie | the EC driver is hacky as shit | 03:01 |
| twb | EC? | 03:01 |
| lilstevie | event controller | 03:01 |
| lilstevie | controlls the keyboard and mouse | 03:02 |
| twb | So like evdev | 03:03 |
| lilstevie | no | 03:04 |
| lilstevie | cause it is hardware | 03:04 |
| twb | Righto | 03:04 |
| lilstevie | the asusec is the controller for the keyboard and mouse | 03:05 |
| twb | Ah, that fucker | 03:05 |
| lilstevie | and a few other little things | 03:05 |
| twb | Quite often in the previous install it would spew printks so fast I couldn't do anything but hard-reboot | 03:05 |
| TheMuso | I was wondering what asusec was for. | 03:07 |
| TheMuso | Nice to know. | 03:08 |
| lilstevie | the asusec does a little more | 03:08 |
| lilstevie | but that is the main thing | 03:08 |
| TheMuso | yup | 03:14 |
| twb | Does tf101 have a hardware AES module? And if so, does ubuntu leverage it? | 03:15 |
| twb | Some of my programs (e.g. mutt) seem to be hanging a lot, and my first guess is they're churning TLS | 03:16 |
| twb | Hm, or it could just be that python is really crap | 03:17 |
| twb | 10602 twb 20 0 8800 3568 1680 R 2 0.5 0:00.09 python -c import netrc; print netrc.netrc().authenticators('imap.cyber.com.au')[0] | 03:17 |
| lilstevie | yes, and not really at this point I guess | 03:17 |
| lilstevie | never tried | 03:17 |
| lilstevie | but there is hardware aes | 03:18 |
| twb | Since bt isn't working atm I'm doing this: update-rc.d bsp-tf101 disable | 03:20 |
| twb | So at least I can halt reliably for now | 03:20 |
| lilstevie | heh | 03:20 |
| lilstevie | fair enough | 03:20 |
| lilstevie | the other stuff in the bsp is for CrOS kernel so it wont affect you | 03:20 |
| twb | So next week when I come in yelling that it isn't starting, that is why ;-) | 03:20 |
| lilstevie | haha ok | 03:21 |
| twb | lilstevie: is there a way to detect (programmatically) if the dock is attached? | 04:15 |
| infinity | I'd assume the extra devices show up in /sys somewhere? | 04:19 |
| twb | http://paste.ubuntu.com/769703/ little /etc/cron.hourly/battery job I wrote to get a feel for battery consumption rate | 04:20 |
| twb | infinity: unfortunately no, they still appear and if you cat them it complains to all the login ttys | 04:20 |
| twb | infinity: so right now I think that cron job will print gank all over my screen occasionally | 04:20 |
| twb | (I also have a battery monitor in .screenrc, but that's not logging, so I can't look at the rate-of-change.) | 04:21 |
| twb | tegra-i2c tegra-i2c.3: no acknowledge; tps6586x 4-0034: failed reading at 0x20; Failed to set dvfs regulator vdd_cpu; Failed to set regulator vdd_cpu for clock cpu to 1000 mV; cpu-tegra: Failed to set cpu frequency to 1000000 kHz | 04:24 |
| twb | ^^ any idea whart those dmesg's are about? It sounds like it's failing to save my battery | 04:24 |
| twb | lilstevie: btw why was apmd installed instead of acpid? | 04:29 |
| twb | lilstevie: is apmd an OMAPism? | 04:29 |
| twb | And more importantly, is suspend-to-RAM working yet? | 04:30 |
| lilstevie | there is no acpi on arm | 04:43 |
| lilstevie | and no suspend functions do not work | 04:43 |
| lilstevie | well more correctly waking up from suspend functions does not work properly | 04:43 |
| twb | lilstevie: well, acpi_listen can see hardware keys being pressed | 04:52 |
| twb | That's how I'm triggering shutdowns right now | 04:52 |
| twb | (re suspend -- OK, thanks.) | 04:52 |
| infinity | lilstevie: Hrm, suspend is working on the ac100. Perhaps some bits need merging between trees? | 04:53 |
| lilstevie | twb: my point is acpi is not really all there for arm | 04:54 |
| lilstevie | infinity: no | 04:54 |
| lilstevie | infinity: already spoke to ogra et al. with that | 04:54 |
| lilstevie | the ac100 used some nvec stuff for it | 04:54 |
| lilstevie | we don't use nvec | 04:54 |
| infinity | Ah. | 04:54 |
| twb | lilstevie: OK, hardware-wise I see your point. From a practical perspective, should I uninstall acpid and install something "better"? | 04:54 |
| lilstevie | and, the issue with suspend is the framebuffer | 04:55 |
| twb | (The goal being to respond to power/volup/voldn and kb media buttons like brightup/brightdn) | 04:55 |
| lilstevie | twb: evdev does that :p | 04:55 |
| twb | I mean without resorting to gnome-power-manager or kpowerwhatever | 04:56 |
| lilstevie | oh i see | 04:56 |
| twb | In the x86 world you just install acpid and acpi-support, but for some reason oneiric doesn't even seem to *have* an acpi-support package | 04:56 |
| lilstevie | well that is a bit more difficult | 04:56 |
| lilstevie | and yes, that is because we don't have acpi tables | 04:56 |
| twb | lilstevie: right now acpid is WORKING, which is partly why I'm confused. | 04:56 |
| lilstevie | as in, not at all | 04:56 |
| lilstevie | we have a kernel maintained device tree | 04:57 |
| lilstevie | which will fill in a few of the blanks | 04:57 |
| lilstevie | but not enough | 04:57 |
| twb | twb@elba[Desktop]$ config.guess ==> armv7l-unknown-linux-gnu | 04:57 |
| twb | twb@elba[Desktop]$ acpi_listen ==> video/brightnessup BRTUP 00000086 00000000 | 04:57 |
| lilstevie | infinity: anyway, after suspend, the framebuffer keeps getting suspended | 04:57 |
| lilstevie | infinity: under CrOS_2.6.38 it is worse :p it doesn't even wake up | 04:58 |
| lilstevie | and twb right, there are some standard features which will | 04:59 |
| twb | Ah, OK | 05:00 |
| TheMuso | Does android actually suspend the tf though when you leave it or press the power button? | 05:00 |
| twb | So the kernel is basically faking it | 05:00 |
| lilstevie | TheMuso: yes | 05:00 |
| TheMuso | Ah ok. | 05:00 |
| TheMuso | Very responsive in coming back then. | 05:00 |
| lilstevie | TheMuso: the difference is minimal | 05:01 |
| lilstevie | sometimes when you wake it up it is instant, that did not go all the way to LP0 | 05:01 |
| lilstevie | when there is about 1-1.5sec lag, that is waking up from WB0/LP0 | 05:01 |
| TheMuso | ah ok. | 05:03 |
| twb | Are they registers or what? | 05:04 |
| twb | Hmm, http://www.faqs.org/patents/app/20090204837 ? | 05:04 |
| lilstevie | kinda | 05:05 |
| lilstevie | PMIC | 05:05 |
| lilstevie | which has control registers | 05:06 |
| twb | btw, can I use any old mains<-->usb power brick? | 05:07 |
| lilstevie | no | 05:07 |
| twb | Bugger | 05:08 |
| twb | I want a second one to leave in the office rather than carrying it with me every day | 05:08 |
| lilstevie | how typical | 05:09 |
| lilstevie | trying to debug the suspend issue | 05:09 |
| lilstevie | cant trig the damn bug | 05:09 |
| lilstevie | actually | 05:10 |
| lilstevie | thats a good thing | 05:10 |
| TheMuso | lol | 05:10 |
| lilstevie | this is the first time I have done it dockless | 05:10 |
| TheMuso | THat means something. | 05:10 |
| lilstevie | maybe the bug is in the dock resume :p | 05:10 |
| TheMuso | Or something USB. | 05:10 |
| TheMuso | WHich doesn't surprise me. | 05:10 |
| lilstevie | hah | 05:10 |
| twb | What interconnect does the dock use anyway? I just kinda assumed it was power + usb | 05:11 |
| lilstevie | a very complex interconnect | 05:11 |
| twb | plus a few other random pins, of course | 05:11 |
| twb | lilstevie: custom asus one, or custom tegra one? | 05:11 |
| lilstevie | usb+gpio+power+i2c+i2s | 05:11 |
| twb | (As if USB isn't complex enough interconnect on its own :P) | 05:12 |
| lilstevie | the keyboard runs off a combination of GPU+i2c | 05:12 |
| lilstevie | er | 05:13 |
| lilstevie | GPIO | 05:13 |
| twb | heh | 05:13 |
| TheMuso | Oh wow, I thought the keyboard would be USB. | 05:13 |
| lilstevie | the mouse is i2c and i2s | 05:14 |
| TheMuso | Even more weird. | 05:14 |
| lilstevie | well not really | 05:15 |
| twb | mouse as in touchpad? | 05:15 |
| lilstevie | it implements a ps/2 like interface over that | 05:15 |
| lilstevie | yes | 05:15 |
| TheMuso | I guess they wanted to keep the USB free for the USB ports. | 05:15 |
| lilstevie | well technically the USB controller is in the dock ;) | 05:15 |
| TheMuso | Yeah, another UBhub... | 05:15 |
| twb | if I was doing it, I'd have just run the keyboard and touchpad as USB off a UHCI controller in the dock | 05:15 |
| TheMuso | usb hub... | 05:15 |
| lilstevie | the keyboard is based of nvex | 05:16 |
| twb | How many ports can your typical UHCI controller have soldered onto it? Four? Eight? | 05:16 |
| lilstevie | nvec* | 05:16 |
| lilstevie | gpio is the primary interface | 05:16 |
| twb | If it was four you could just have two ports on the dock, plus one for the kb and one for the tp | 05:17 |
| lilstevie | TheMuso: can you tack on to that blueprint that I need to reverse the off state for the lid switch | 05:18 |
| lilstevie | :p | 05:18 |
| lilstevie | and also, right on queue | 05:18 |
| TheMuso | lilstevie: What does it have to do with that daemon | 05:18 |
| lilstevie | dock+suspend == bad times | 05:18 |
| lilstevie | TheMuso: nothing, just it is dock related :p | 05:18 |
| TheMuso | lilstevie: Fair enough. You hsould have write access to the whiteboard of the blueprint... | 05:19 |
| TheMuso | But I can add it. | 05:19 |
| lilstevie | yeah I just CBF :p | 05:19 |
| lilstevie | I really should do a kernel blueprint | 05:19 |
| TheMuso | Yeah that would be good, I would like to know what you have planned. | 05:20 |
| lilstevie | heh :) | 05:20 |
| lilstevie | that kinterruptive stuff also is interconnected with the dock :( | 05:21 |
| lilstevie | no trace of it in my dmesg, connect dock, bam | 05:21 |
| TheMuso | lilstevie: added. | 05:21 |
| lilstevie | ta | 05:21 |
| lilstevie | ok, so will not suspend with the usb cord plugged in :p | 05:22 |
| TheMuso | lol I love it when one gets side tracked from something else because the point of discussion is interesting enough to dig deeper into a problem. :) | 05:24 |
| lilstevie | heh :p | 05:25 |
| lilstevie | well I have been meaning to dig deeper into suspend | 05:26 |
| lilstevie | cause man will that push batt life to extreme levels | 05:26 |
| TheMuso | Yep. | 05:26 |
| lilstevie | f*** it | 05:29 |
| lilstevie | I cant trigger the damn bug again | 05:29 |
| lilstevie | this is annoying, it is what happens every time | 05:29 |
| TheMuso | heh | 05:30 |
| lilstevie | and when i do trigger it, I am nowhere near a computer that will allow me to remote access it and get detailed logs rather than a 500ms flash | 05:30 |
| lilstevie | holy crap | 05:31 |
| lilstevie | I don't believe it | 05:31 |
| twb | I want to run sleepd | 05:31 |
| lilstevie | plugging in the usb cable, hooked to the computer stops the bug | 05:32 |
| twb | Which basically just does pm-suspend if it hasn't seen keyboard input for ten minutes | 05:32 |
| lilstevie | unplug, bang it is back | 05:32 |
| twb | Actually I should install it now and just configure it to turn off the backlight | 05:32 |
| twb | Since that's like 30% of the power drain | 05:32 |
| TheMuso | lilstevie: weird. | 05:33 |
| TheMuso | Anyway, gotta run. | 05:33 |
| lilstevie | TheMuso: weird is right, plug usb cable in, resume bug goes away | 05:34 |
| lilstevie | unplug it, within 30s bug starts back | 05:34 |
| lilstevie | later TheMuso | 05:34 |
| lilstevie | got it | 05:41 |
| lilstevie | TheMuso: when you are around; figured out why it locks when the usb plug is in | 05:42 |
| lilstevie | TheMuso: when the usb plug is in it prevents suspend. when unplugged it gets into a suspend/wake loop | 05:43 |
| lilstevie | now just need to figure out why wake from suspend goes into a suspend/wake loop | 05:43 |
| twb | mplayer says: mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking | 06:28 |
| twb | sudo mplayer http://radio1.internode.on.net:8000/117 ==> mplayer: relocation error: mplayer: symbol __aeabi_f2ulz, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference | 06:29 |
| twb | >sad face< | 06:30 |
| twb | Hmm, that's mplayer1 | 06:35 |
| * twb tries mplayer2 | 06:35 | |
| twb | Same issue with mplayer2 | 06:38 |
| lilstevie | ok I am kinda getting a little confused | 06:42 |
| micahg | twb: which releasE? | 06:42 |
| lilstevie | also mplayer would be terrible on unaccelerated hw | 06:42 |
| micahg | there was a compiler issues which had libav emitting extra symbols on oneiric IIRC | 06:43 |
| twb | I only want audio | 06:43 |
| twb | It's just my scripts are set up to assume mplayer atm | 06:43 |
| lilstevie | micahg: this is on oneiric | 06:43 |
| micahg | ah, mplayer might need a rebuild if it's failing | 06:43 |
| twb | I could probably learn xmms2 or something but today ICBF | 06:43 |
| lilstevie | ok, so this is what is happening | 06:43 |
| twb | lilstevie: won't *all* video be sucky without hw accel -- not just mplayer? | 06:44 |
| lilstevie | as soon as the wake lock is removed (by unplugging the usb cable) suspend: sys_sync; suspend: enter suspend | 06:44 |
| lilstevie | twb: actually | 06:44 |
| lilstevie | all video will be sucky even with acceleration | 06:44 |
| twb | Why? | 06:45 |
| lilstevie | until you start doing processing on the AVP | 06:45 |
| lilstevie | cause tegra sucks ass | 06:45 |
| twb | k | 06:45 |
| twb | My simple-minded brain reduces that down to "hardware acceleration" | 06:45 |
| lilstevie | ok, so basically as soon as every last piece of hw has come back from suspend; it calls back to suspend 0.o | 06:46 |
| lilstevie | no idea why | 06:46 |
| lilstevie | twb: it is a little more complex than that, the GPU is weak | 06:46 |
| twb | to save power duh :P | 06:46 |
| lilstevie | twb: yeah but it resumes from the recalled suspend after 0.310sec | 06:47 |
| twb | eh I am coming from matrox and intel | 06:47 |
| lilstevie | ^^measured by the kernel timer | 06:47 |
| lilstevie | twb: no what i mean is the tegra GPU is really weak | 06:47 |
| twb | even weaker than an i915? | 06:47 |
| lilstevie | unless video gets preprocessed by the AVP | 06:47 |
| twb | Wow | 06:47 |
| twb | hum, ok | 06:48 |
| lilstevie | for mpeg vid | 06:48 |
| lilstevie | thats what all those .axf files are in /lib on android | 06:48 |
| lilstevie | they are programs for the avp to aid decoding | 06:48 |
| twb | presumably that's only useful if you're watching video, tho | 06:49 |
| twb | not e.g. playing doom | 06:49 |
| lilstevie | yes | 06:50 |
| lilstevie | correct | 06:50 |
| twb | Righto | 06:50 |
| twb | btw for some reason when I rebooted out of android, the caps lock light was on, and it won't turn off | 06:57 |
| twb | (Which is a surprise to me; I didn't even know there WAS a light.) | 06:57 |
| lilstevie | lol | 06:57 |
| twb | micahg: there's this libavcodec-extra-53 that Provides libavcodec53, is it also likely to be buggered? | 07:11 |
| micahg | twb: idk | 07:11 |
| * twb tries | 07:11 | |
| twb | answer: it does | 07:13 |
| twb | Er, "libavcodec-extra-53 is also buggered" | 07:13 |
| lilstevie | hm | 07:16 |
| lilstevie | http://pastie.org/3014429 | 07:17 |
| twb | lilstevie: how do you get that out? netconsole? | 07:18 |
| twb | (assume you're still banging against suspend issues.) | 07:18 |
| lilstevie | because once you plug in the USB it triggers wake lock | 07:18 |
| twb | Ah | 07:19 |
| lilstevie | it seems to fully wake up | 07:19 |
| lilstevie | then bam out of nowhere suspends again | 07:19 |
| twb | Does the suspend key have a down and an up event? | 07:20 |
| lilstevie | which is what that portion of the dmesg is | 07:20 |
| lilstevie | it isn't that :p | 07:20 |
| twb | Maybe it suspends before the up even arrives, so it thinks you're still holding it down | 07:20 |
| twb | OK | 07:20 |
| lilstevie | I called suspend from the power menu :) | 07:20 |
| twb | What happens if you throw away the GUI and call it from /sys ? ;-P | 07:20 |
| lilstevie | no idea really :p | 07:21 |
| lilstevie | the only way I know to suspend from /sys isn't in the kernel | 07:21 |
| twb | Might be /proc I forget | 07:22 |
| twb | Something like echo mem > /sys/power/state | 07:25 |
| lilstevie | yeah | 07:26 |
| twb | And if you cat it it tells you someting like "swap mem" to mean it supports suspend to both disk and ram | 07:26 |
| twb | Of course that's JUST suspending, and pm-utils and friends do all sorts of crazy shit in addition to that to work around failtastic hw | 07:26 |
| lilstevie | only supports mem | 07:26 |
| twb | like halting bt and turning all the LEDs off and rmmoding things | 07:27 |
| twb | It wouldn't surprise me in the slightest if one of those things was actually CAUSING the resume problems | 07:27 |
| lilstevie | lol | 07:28 |
| lilstevie | I will try it | 07:28 |
| lilstevie | :) | 07:28 |
| lilstevie | just need to call reboot | 07:28 |
| twb | I bet you get new and excitingly different problems | 07:28 |
| lilstevie | something has to be calling suspend | 07:28 |
| twb | Just remember to turn off the GUI and esp. gnome-power-manager first | 07:28 |
| lilstevie | heh | 07:28 |
| lilstevie | service lightdm stop | 07:29 |
| lilstevie | problem solved | 07:29 |
| twb | You could just "stop lightdm" | 07:29 |
| lilstevie | fwiw identical result | 07:32 |
| lilstevie | well surface is identical | 07:32 |
| lilstevie | will check out the dmesg in 2 secs | 07:32 |
| twb | k | 07:33 |
| lilstevie | yep same result | 07:38 |
| twb | Aw | 07:39 |
| twb | Well at least we know it's not any of the helper code now | 07:39 |
| lilstevie | yeah | 07:39 |
| lilstevie | which I already figured anyway :) | 07:39 |
| lilstevie | the most I can see at the moment is a kernel owned task is calling the suspend | 07:40 |
| lilstevie | as part of the end of waking up from suspend | 07:40 |
| twb | So-rry | 07:40 |
| lilstevie | :p | 07:41 |
| twb | You can just tell me to STFU if I'm not helping | 07:41 |
| lilstevie | worth a try though to confirm | 07:41 |
| lilstevie | STFU every little idea helps | 07:42 |
| twb | maybe... it only happens when you hold the tablet upside down! | 07:43 |
| lilstevie | lol | 07:43 |
| lilstevie | well I may have been misinterpreting the log | 07:44 |
| twb | WTF | 07:57 |
| twb | festival --tts book, half a sentence in it goes "=== PAUSE ===" | 07:57 |
| twb | That has never happened before | 07:57 |
| twb | Goddammit, no bedtime stories for me tonight | 08:01 |
| twb | The actual thing pausing is aplay AFAICT | 08:02 |
| twb | Hmm, why does free -m say I only have 728MB of RAM? | 08:04 |
| twb | Surely it doesn't need >256MB reserved for the GPU or something? :-/ | 08:04 |
| twb | Anyway, home time. | 08:05 |
| _Thomas | Hmm, I have this usb wifi stick that works with open access points, but when I try to connect to encrypted ones, it fails to connect | 10:38 |
| _Thomas | (I'm trying to connect using the network wizzard) | 10:38 |
| _Thomas | erh, Network Manager | 10:38 |
| ogra_ | is that with one of the official ubuntu images from cdimage ? | 10:41 |
| _Thomas | ogra_: No it's linaro's ubuntu-based image, but it's using most of it's packages from the ubuntu pool | 10:43 |
| ogra_ | that doesnt matter, they are built differently (using metapackages instaed of tasks which can result in different package/dependency selection) | 10:44 |
| ogra_ | so you might miss something | 10:44 |
| ogra_ | do you see any messages in dmesg ? | 10:45 |
| _Thomas | ogra_: yes, I got some messages in dmesg | 10:55 |
| ogra_ | pastebin them | 10:55 |
| ogra_ | it could also be a missing kernel config option or so | 10:55 |
| ogra_ | or missing firmware etc | 10:55 |
| ogra_ | btw, what HW is that ? | 10:56 |
| _Thomas | ogra_: http://pastebin.com/Qwrs3a3e | 10:58 |
| _Thomas | rtl8187 | 10:58 |
| ogra_ | do you see it loading the right firmware (thats not in your dmesg, a full copy would have been better than a snippet) | 10:59 |
| ogra_ | and do you have linux-firmware installed ? | 11:00 |
| _Thomas | I can yank out the stick, and put it back in again | 11:00 |
| ogra_ | yeah, check if you see anything about firmware and also check if you have that package installed | 11:00 |
| ogra_ | and again, what hardware is that ? | 11:01 |
| _Thomas | RTL8187, as I said above :) | 11:02 |
| xranby | _Thomas: which board are you using? | 11:03 |
| xranby | kernel source tree etc | 11:03 |
| ogra_ | right | 11:04 |
| _Thomas | my own board, kernel source tree is linux-samsung tree | 11:04 |
| xranby | ah right. you make the libEGL for that not yet released samsung board? | 11:05 |
| _Thomas | :) | 11:05 |
| xranby | it is the Origen board? | 11:06 |
| _Thomas | xranby: No, but it's the same AP | 11:07 |
| xranby | _Thomas: can you check if the same bug exist on the Origen boarD? | 11:08 |
| * ogra_ would guess its either a missing kernel option or some package missing | 11:08 | |
| _Thomas | xranby: Kind of hard, since I don't have any origen boards | 11:09 |
| _Thomas | ogra_: Maybe, but I don't see what could be missing from the kernel | 11:10 |
| ogra_ | i dont either since i dont know your kernel ... the ubuntu kernels have a good bunch of common options they all share and that specifically is true for external devices like USB ... | 11:11 |
| ogra_ | (and independent of arch etc) | 11:12 |
| _Thomas | But could this be USB related, given that the device is detected, and works with open APs? | 11:13 |
| ogra_ | unlikely ... but it could for example be driver related | 11:13 |
| _Thomas | And with the regards to cfg80211, I've enabled almost everything (only debugging parts not enabled) | 11:13 |
| ogra_ | probably you should :) | 11:14 |
| ogra_ | might get you some more insight (even though it seriously spams dmesg) | 11:14 |
| _Thomas | with regards to the driver itself, there was no options to choose from | 11:15 |
| _Thomas | other than mode / integrated / none | 11:15 |
| _Thomas | mode=module | 11:15 |
| _Thomas | and I chose to compile as module | 11:15 |
| ogra_ | no, but there might be patches we have in ubuntu and you are missing | 11:15 |
| _Thomas | that is true | 11:15 |
| _Thomas | I'm running 3.2-rc1 | 11:16 |
| ogra_ | what kernel version is that ? | 11:16 |
| _Thomas | fairly recent | 11:16 |
| ogra_ | ah, same we have for panda and omap3 | 11:16 |
| ogra_ | that should do | 11:16 |
| ogra_ | not sure about possible patches though, #ubuntu-kernel might be able to talk about these | 11:16 |
| _Thomas | I tested the same USB-stick on regular ubuntu 11.04 (x86, that is) | 11:17 |
| _Thomas | with same issue | 11:17 |
| ogra_ | aha | 11:17 |
| _Thomas | I had forgot about that until now :D | 11:17 |
| _Thomas | Should all sticks download firmware? | 11:20 |
| _Thomas | because there's nothing about firmware in the loggs | 11:20 |
| _Thomas | not even about failed download/upload or anything | 11:21 |
| ogra_ | it might not report it if its successfull | 11:21 |
| _Thomas | ok, so it's safe to rule out firmware, then | 11:21 |
| ogra_ | ogra@horus:~$ ls /lib/firmware/rtlwifi/ | 11:21 |
| ogra_ | rtl8192cfw.bin rtl8192cufw.bin rtl8192defw.bin rtl8192sefw.bin rtl8712u.bin | 11:21 |
| ogra_ | thats what i have on my machine in oneiric | 11:22 |
| _Thomas | no 8187 there | 11:22 |
| ogra_ | no, but often firmware files apply to multiple devices | 11:22 |
| ogra_ | if you actually have the same prob on other HW with the same device i would go to #ubuntu-kernel and ask there | 11:23 |
| ogra_ | oh, and there is bug 802902 | 11:25 |
| ubot2 | Launchpad bug 802902 in linux "Realtek rtl8187b wireless chipset slow speed" [Undecided,Confirmed] https://launchpad.net/bugs/802902 | 11:25 |
| ogra_ | the last comment is intresting | 11:25 |
| _Thomas | I don't have the b-version of the chipset, it seems | 11:30 |
| === apachelogger_ is now known as apachelogger | ||
| === doko_ is now known as doko | ||
| ogra_ | doko, just playing with the ac100 you gave me .... as i thought, the kbd cable was only half plugged in | 12:17 |
| ogra_ | armhf feels quite a bit snappier on the desktop i must say | 12:17 |
| lilstevie | ogra_: heh yeah hf is amazing | 12:22 |
| lilstevie | is libreoffice working on hf yet? | 12:22 |
| ogra_ | nope, didnt build yet | 12:22 |
| ogra_ | patches accepted | 12:22 |
| lilstevie | ah ok | 12:22 |
| ogra_ | ;) | 12:22 |
| doko | ogra_, including the mmap fix? | 12:23 |
| ogra_ | doko, no idea if janimo included that in the precise upload from yesterday | 12:24 |
| ogra_ | i'll upgrade to the 3.0 kernel soon | 12:24 |
| doko | janimo, ^^^ ? | 12:24 |
| ogra_ | for now i want to see how much rendering improves by using hf | 12:24 |
| ogra_ | firefox seems to scroll a lot smoother | 12:25 |
| doko | lool, could you care about the flash-installer merge? | 12:34 |
| ogra_ | doko, we are still discussiong it | 12:34 |
| ogra_ | its not clear yet if we will switch at all | 12:35 |
| doko | ahh, ok, so not mine | 12:35 |
| ogra_ | oh, wait you mean adobe flash? | 12:35 |
| ogra_ | or flash-kernel | 12:35 |
| ogra_ | (flash-installer is adobe, no ?) | 12:37 |
| ogra_ | infinity, are you around today or still ill ? | 13:29 |
| * ogra_ is about to roll an nvidia-tegra driver for precise restricted/multiverse and could need a package review in NEW then | 13:30 | |
| xranby | ogra_: have you obtained a armhf version? | 13:40 |
| ogra_ | no | 13:40 |
| ogra_ | up to nvidia to provide one | 13:40 |
| ogra_ | i dont see aaronp in #ac100 anymore, else i would have asked him | 13:41 |
| ogra | armhf rocks :) | 14:09 |
| lilstevie | heh | 14:11 |
| xranby | ogra: yes yes i find it nifty | 14:11 |
| ogra | now a binary driver would really be lovely | 14:11 |
| xranby | ogra: right now im also using 256kb default stack by setting * soft stack 256 in /etc/security/limits.conf | 14:12 |
| xranby | and my armhf system ticks on fine without any zram swap tricks | 14:12 |
| ogra | just that line ? | 14:13 |
| ogra | * soft stack 256 | 14:13 |
| ogra | ? | 14:13 |
| xranby | yes | 14:13 |
| * ogra adds it | 14:13 | |
| ogra | anything i need ot restart for it to take effect ? | 14:13 |
| xranby | it makes pthread's use 256kb stack by default instead of 8Mb for each thread | 14:14 |
| ogra | well, i guess i'll reboot | 14:14 |
| xranby | in my humble optinion: since a ubuntu unity2d system + browser open runs around 321 running threads the default pthread stack size do matter | 14:19 |
| xranby | ogra: how does things look on your side? | 14:19 |
| ogra | what should be the difference with thet security conf setting | 14:19 |
| ogra | there is no feelable difference it seems | 14:19 |
| xranby | newly started programs threads should use less memory fore each thread by default | 14:20 |
| xranby | programs can still opt in for more stack for each thread.. as i have understood it | 14:20 |
| ogra | hm. k | 14:20 |
| ogra | we'll see over time i guess | 14:20 |
| ogra | hmm, actually seems to eat less ram | 14:21 |
| xranby | ogra: now ulimit -a should report stack size 256kb | 14:21 |
| xranby | yes, thats the idea | 14:22 |
| xranby | programs start to use less ram automagically | 14:22 |
| ogra | it does indeed | 14:22 |
| ogra | i wonder what the implications would be if we set it by default | 14:22 |
| xranby | dont set it too low. if the default are 64kb then unity will not work around 128kb jsome woud have trouble unzipping stuff 256 looks fine for most applications that i have tested | 14:24 |
| ogra | k | 14:25 |
| ogra | well, what i mean is ... there doesnt seem to be any default value in the file | 14:25 |
| ogra | and i wonder if there is a reason for this | 14:25 |
| xranby | the default have increased during the last years, i think the default are set in eglibc source | 14:26 |
| ogra | ah, not a kernel thing then | 14:26 |
| xranby | some years ago the default thread size on x86 was 2Mb now its 8Mb for most architectures | 14:26 |
| dmart | ogra, xranby: does changing the stack limit make much of a difference in practice? I though the memory wasn't really allocated in advance... this just controls how much VMA space is reserved for stack growth | 14:26 |
| ogra | doko, any thoughts on the above | 14:26 |
| ogra | dmart, well, htop shows a *lot* less ram used | 14:27 |
| ogra | with the stuff i have open atm i would usually hit 400M or so | 14:27 |
| ogra | and it only reports about 280 | 14:27 |
| dmart | Interesting. What is that actually measuring, though? | 14:28 |
| ogra | htop ... i think it sums up RES | 14:28 |
| ogra | not sure though | 14:28 |
| dmart | Interesting if so | 14:29 |
| lilstevie | I just got LP0 suspend working on tf101 | 14:43 |
| lilstevie | :D | 14:43 |
| ogra | awesome ! | 14:43 |
| dmart | ogra: try http://pastebin.ubuntu.com/770100/ | 14:43 |
| dmart | This should help to give an idea of just the thread overhead | 14:43 |
| dmart | With 8M stacksize, I get an overhead of about 8.4K per thread | 14:44 |
| dmart | (measuring PSS with smem)( | 14:44 |
| lilstevie | ogra: it was something basic too | 14:45 |
| lilstevie | ogra: wakelocks were interfering; damn android | 14:45 |
| ogra | dmart, ok, i get 768 with my current setup | 14:45 |
| ogra | i bet i cant change the value without a reboot | 14:46 |
| dmart | 768 what? | 14:46 |
| xranby | ogra: ulimit -s 4096 | 14:46 |
| xranby | etc | 14:46 |
| ogra | dmart, it prints 768 threads created. | 14:46 |
| dmart | Just increase THREAD_COUNT ... the choice of value was totally arbitrary | 14:47 |
| xranby | ogra: ulimit -s 8192 | 14:47 |
| dmart | oddly though, on an ARM board it only creates 157 thread | 14:47 |
| xranby | thats the ubuntu default | 14:47 |
| xranby | dmart: why is that odd? | 14:47 |
| ogra | with 4096 i get only 451 threads | 14:47 |
| xranby | dmart: if you use 8Mb for each thread | 14:47 |
| ogra | 8192 gets me an error | 14:48 |
| ogra | seems i'm exceeding the limit | 14:48 |
| dmart | Ah, OK, the kernel may require 8MB of backing per thread | 14:48 |
| xranby | dmart: it simply means that you have exausted the process adress space quickly by consuming 1.2gb of ram | 14:48 |
| xranby | dmart: run ulimit -s 256 | 14:48 |
| xranby | and then rerun the test | 14:48 |
| dmart | xranby: ah, yes of course | 14:49 |
| ogra | bah, and now i cant set anything else but 256 anymore | 14:49 |
| dmart | xranby: this shouldn't affect the memory load on the system overall | 14:49 |
| dmart | afaik | 14:49 |
| ogra | thats not really consistent | 14:49 |
| xranby | it does.. if one application consume all ram on the system + all swap as your 768threads*8Mb | 14:50 |
| xranby | would do | 14:50 |
| xranby | then no program can fork | 14:50 |
| xranby | and leave your system in a locked up state | 14:50 |
| dmart | xranby: right, with ulimit -s 256 I get 768 threads. But we're not consuming RAM here, just virtual address space in that particular process. | 14:50 |
| dmart | xranby: that only happens if overcommit is enabled, and if all those threads actually use 8MB of stack | 14:51 |
| ogra | well, running the same stuff on my oneiric armel installed device it starts swapping already | 14:51 |
| dmart | 99% of threads don't use anything like 8MB of stack | 14:51 |
| dmart | (which is just as well) | 14:51 |
| ogra | on this armhf install and with the ulimit set to 256 it only uses 00M | 14:51 |
| ogra | 300M | 14:52 |
| dmart | I guess my question is: why does changing the default stack size actually make a difference? | 14:52 |
| xranby | dmart: do pthread zero the stack? | 14:55 |
| xranby | i have to check | 14:55 |
| dmart | xranby: normally, zeroing the stack would be unnecessary. Maybe there are some specific processes allocting their threads' memory explicitly via another mechanism | 14:56 |
| dmart | If so, then changing the default stack size system-wide might make a big difference to the memory consumption of some processes but not others | 14:56 |
| dmart | xranby: I can't see anything in the pthread_create manpage about pre-zeroing of stacks, and it obviously doesn't happen for my silly test | 14:58 |
| xranby | dmart: freebsd have for a long time used a default of 64Kb pthread stack size | 15:01 |
| xranby | dmart: i think your question are all valid.. i really dont know why the memory gets consumed | 15:01 |
| dmart | ogra: maybe you could run smem with the two stacksize defaults, and see where the memory consumption changes | 15:02 |
| xranby | in linux where we allow all programs to overcommit we usually like solutions that allow programs to grab a large block of memory and rely on the linux OOM kilelr to kill the most suitable overcommiter | 15:03 |
| dmart | indeed... | 15:03 |
| ogra | geez | 15:11 |
| ogra | i have a load of 18 | 15:11 |
| ogra | and there goes firefox | 15:11 |
| ogra | seems it didnt like the 25th tab i opened | 15:12 |
| * ogra wonders why janimo's ac100 3.0 upload doesnt show up yet ... it should be published by now | 15:16 | |
| ogra | apt only offers me linux-image-2.6.38-1002-ac100 | 15:17 |
| xranby | ogra: interesting indeed they are seen here https://launchpad.net/ubuntu/+source/linux-ac100/3.0.8-1.1/+build/3007924 | 15:20 |
| ogra | probably stuck in the NEW queue | 15:21 |
| xranby | janimo: https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/904313 any possible config issue? | 15:54 |
| ubot2 | Launchpad bug 904313 in linux-ac100 "boot failure using linux-image-3.0.8-1-ac100_3.0.8-1.1 armhf precise" [Undecided,New] | 15:54 |
| infinity | ogra: I'm around today. | 15:55 |
| ogra | k | 15:56 |
| infinity | ogra: Still feeling ill, but I only have two days left at work, I figure I'll tough it out. :P | 15:56 |
| ogra | i was a bit distracted from the driver | 15:56 |
| ogra | so i didnt do much about it yet, but will | 15:56 |
| ogra | playing with armhf on the ac100 is exciting := | 15:56 |
| ogra | :) | 15:56 |
| * ogra installs the 3.0.8 kernel from janimo | 15:57 | |
| xranby | i have got my system bootable again by reverting back to the 2.6.38-1002-ac100 kernel | 15:58 |
| ogra | WOAH ! | 15:58 |
| ogra | update-initramfs: Generating /boot/initrd.img-3.0.8-1-ac100 | 15:58 |
| ogra | *** stack smashing detected ***: /bin/sh terminated | 15:58 |
| ogra | Aborted (core dumped) | 15:58 |
| ogra | E: /usr/share/initramfs-tools/hooks/udev failed with return 134. | 15:59 |
| ogra | geez, that looks bad | 15:59 |
| ogra | xranby, might not be the kernel at all | 15:59 |
| xranby | hmm i see | 15:59 |
| infinity | You see weird things on your ac100 that no one else does. I'm convinced you have bad RAM. | 15:59 |
| xranby | infinity: me or ogra? | 16:00 |
| ogra | well, i poked around in /etc/security/limits.conf, might be related :) | 16:00 |
| ogra | ogra@amun:~/Downloads$ sudo update-initramfs -u -k 3.0.8-1-ac100 | 16:00 |
| ogra | update-initramfs: Generating /boot/initrd.img-3.0.8-1-ac100 | 16:00 |
| ogra | Writing boot image to /dev/mmcblk0p4 ... done. | 16:01 |
| ogra | a manual run works fine | 16:01 |
| ogra | lets see if it comes back up again | 16:01 |
| * ogra reboots | 16:01 | |
| infinity | xranby: ogra. | 16:02 |
| ogra_ | nope, same issue here | 16:02 |
| ogra_ | hangs at the toshiba logo | 16:03 |
| ogra_ | janimo, did you actually test that kernel before uploading it ? | 16:03 |
| * ogra_ curses ... i just prodded pitti to let it out of NEW, now the images wont boot :( | 16:04 | |
| infinity | Oops. | 16:04 |
| infinity | meta's been updated too? :/ | 16:04 |
| ogra_ | indeed assuming janimo at least booted it once | 16:04 |
| ogra_ | no, neta isnt yet | 16:04 |
| ogra_ | luckily | 16:04 |
| infinity | Okay, so not world-ending yet. | 16:04 |
| ogra_ | indeed | 16:05 |
| infinity | Cause only people who know it's there will upgrad. | 16:05 |
| infinity | e | 16:05 |
| ogra_ | yep | 16:05 |
| infinity | Compare configs from 2.6.38 and 3.0.8 and see if there are any obvious differences? | 16:06 |
| ogra_ | there will surely be | 16:06 |
| ogra_ | let me boot back into .38 first | 16:06 |
| * ogra twiddles thumbs waiting for man-db | 16:09 | |
| ogra | infinity, http://paste.ubuntu.com/770198/ | 16:12 |
| ogra | bah, sigh ... DM is gone again | 16:14 |
| ogra | -CONFIG_BLK_DEV_DM=m | 16:14 |
| ogra | +# CONFIG_BLK_DEV_DM is not set | 16:14 |
| ogra | half of bluetooth too | 16:15 |
| infinity | Yeah, but nothing in there jumps out as an obvious reason for it not booting either. :/ | 16:15 |
| ogra | what is +CONFIG_CPU_RMAP=y ? | 16:16 |
| infinity | Not sure, but it looks gone completely. | 16:16 |
| infinity | Since it's not replaced in the diff with a # not set | 16:16 |
| ogra | yep | 16:16 |
| marvin24 | ogra: maybe +CONFIG_CMDLINE_FROM_BOOTLOADER=y | 16:46 |
| ogra_ | well, we get it from there | 16:46 |
| ogra_ | at least we did in the past | 16:46 |
| marvin24 | if it get the memory wrong, it will crash at logo (or shortly after) | 16:46 |
| ogra_ | ah | 16:46 |
| ogra_ | k | 16:46 |
| ogra_ | i'll let a package build run over night | 16:46 |
| * ogra_ isnt near any cross build machine atm | 16:47 | |
| marvin24 | wait until I checked it myself (I'm back home in an hour) | 16:47 |
| ogra_ | k | 16:47 |
| infinity | ogra: "Overnight"? linux-ac100 should build in a couple of hours on a Panda or ac100, tops. | 16:51 |
| ogra_ | yeah, but i wont start a build right now | 16:51 |
| infinity | (Assuming you export DEB_BUILD_OPTIONS="parallel=2") | 16:51 |
| === prpplague^2 is now known as prpplague | ||
| Sycro5_ | I'm having trouble getting a bluetooth USB dongle to pair with devices on the Pandaboard. I'm running Ubuntu 11.10 and can scan for devices successfully but cannot pair with them. With the onboard bluetooth, I am not even able to turn bt on, which is why i've resorted to the bt USB dongle. Looking for some help getting the pairing working with the dongle, but am happy to revert back to the onboard bt if someone has any sugges | 18:28 |
| ogra_ | i think there is a daemon missing thats not in the ubuntu archive ... search on launchpad there is a bug about bluetooth on panda | 18:29 |
| ogra_ | it points to the upstream sourfce for that daemon iirc | 18:29 |
| Sycro5_ | Yes, I've read that but don't fully understand it. Does this mean that there is no way to get bluetooth working period? | 18:30 |
| ogra_ | you have to build that daemon from source until it is packages | 18:31 |
| ogra_ | *packaged | 18:31 |
| Sycro5_ | hmm...do you know of any resources that describe how to do that? | 18:33 |
| ogra_ | there should be info about this in the upstream source | 18:34 |
| ogra_ | a README or INSTALL doc | 18:34 |
| Sycro5_ | I'm very inexperienced in compiling this type of thing. Do you think I can find a package that someone's already fixed? | 18:42 |
| ogra_ | i dubt that | 18:44 |
| Sycro5_ | bummer. Well thank you for your help | 18:53 |
| infinity | chroot /root dpkg --purge ac100-tarball-installer | 20:21 |
| infinity | cp /root/usr/share/ac100-tarball-installer/zram.conf /root/etc/init/ || true | 20:21 |
| infinity | ogra_: What's wrong with this picture? :P | 20:22 |
| janimo | infinity, what's wrong whit it besides it being shell script :P ? | 20:31 |
| infinity | janimo: The part where he tries to copy a file after he deletes it. :) | 20:37 |
| infinity | Which, I guess, it why it needs the || true... | 20:38 |
| infinity | *cough* | 20:38 |
| GrueMaster | Looks like a perfect example of working code to me (of course I have spent a lot of time reviewing jasper). | 20:42 |
| ogra_ | infinity, whats wrong ? it checks the error handling of cp just fine :P | 22:19 |
| infinity | ogra_: You're kidding, I hope? ;) | 22:20 |
| ogra_ | indeed :) | 22:20 |
| infinity | Phew. I'm sick. Don't toy with me. | 22:20 |
| ogra_ | go back to your eglibc ... | 22:21 |
| infinity | Yeah, yeah. | 22:21 |
| infinity | I uploaded a fix for ac100. | 22:21 |
| ogra_ | saw that, thanks | 22:21 |
| infinity | (noticed the cp failure flash by while I was reinstalling with armhf) | 22:21 |
| ogra_ | was on my list, i hadnt bothered to look at the code yet | 22:21 |
| ogra_ | yeah, i saw it too today and i know about it since release day | 22:22 |
| infinity | Heh. | 22:22 |
| ogra_ | (that it doesnt get installed i knew) | 22:22 |
| infinity | That's okay. I have another bug that's going to drive me nuts now (and I suspect I'll find it and fix it on my holidays because I'm OCD). | 22:22 |
| infinity | My ARM machines all get several copies of udevd running until I restart udev. | 22:23 |
| infinity | Don't have the same behaviour on x86. | 22:23 |
| infinity | And those multiple udevs are doing angry things to CPU time. | 22:23 |
| ogra_ | yeah, i noticed in my ac100 install today that it installed to mmcblk0p14 ... | 22:23 |
| ogra_ | while the installed system sees only up to p7 | 22:24 |
| ogra_ | (which actually is the rootfs) | 22:24 |
| infinity | That's normal, isn't it? | 22:24 |
| ogra_ | i would blame the udev in initrd to not being carried over properly or some such | 22:24 |
| ogra_ | that the initrd sees twice as many block devices ? | 22:24 |
| ogra_ | i doubt thats normal | 22:25 |
| infinity | Either way. udev madness is on my TODO for "later". | 22:25 |
| infinity | I noticed it a long time ago on my mx53, but I was running the ancient Freescale kernel and blamed it on that. :/ | 22:25 |
| infinity | Just noticed it more recently on other machines with distro kernels. | 22:25 |
| infinity | I guess I should have looked into it back then. | 22:26 |
| ogra_ | hmm, i never noticed any udev weirdness until now | 22:26 |
| infinity | It's been happening on my quickstart forever. | 22:26 |
| infinity | Always have to restart udev after boot to kill off all the extra ones. | 22:26 |
| ogra_ | ah, so pre-precice | 22:26 |
| infinity | Yeah, my QS is running oneiric. | 22:27 |
| infinity | Panda and ac100 are precise. | 22:27 |
| infinity | All show the problem. | 22:27 |
| ogra_ | yeah, that sounds like a stick signalfd or some other weird stuff | 22:27 |
| ogra_ | *stuck | 22:27 |
| infinity | Something weird indeed. | 22:28 |
| ogra_ | hmm, checking my fresh install i see 3 instances of udevd | 22:29 |
| ogra_ | the latter two with a four digit pid ... the first one with 236 | 22:30 |
| ogra_ | seems the magic that scott did to carry over the running udevd from the initrd is broken | 22:31 |
| ogra_ | yup and restarting gets me a single process | 22:33 |
| infinity | Might not be arm-specific, but perhaps just a weird race that slow hardware exposes. | 22:39 |
| infinity | I'll poke it "later". | 22:39 |
| infinity | But tonight, I need to finish this eglibc merge and get it in, so I can deal with possible fallout tomorrow. | 22:39 |
| GrueMaster | I'll make sure to test it once it lands so you will have plenty of fallout to keep you semi-active. :P | 22:45 |
| infinity | GrueMaster: Heh. Well, it's a pretty big merge, I'm more worried about x86 fallout, to be honest. But I'll get some time tonight to test before I upload. | 22:47 |
| * GrueMaster wishes maverick on omap4 would just go away. Getting automated installs working with the same ip address everytime is a pita. | 22:52 | |
| GrueMaster | When dealing with a panda pool that is. | 22:52 |
| lilstevie | holy crap | 23:03 |
| lilstevie | TheMuso: battery life with LP0 is stupedious, was in LP0 for 7 hours without dropping a single percent | 23:04 |
| lilstevie | tablet battery 100% dock at 73% | 23:05 |
| infinity | GrueMaster: Can't you just cheat with a backported uBoot? | 23:09 |
| GrueMaster | No, the kernel driver freaks out. I'm already using uboot from oneiric so I can test on newer pandas (maverick only supported A1 due to lookup tables in uboot). | 23:10 |
| GrueMaster | And it is the kernel smsc95xx driver that needs to be fixed. Natty+ uses the cpu die-id to generate a unique mac. | 23:11 |
| GrueMaster | (although that is only on panda, same driver on beagleXM but patch for die-id isn't upstream). | 23:11 |
| infinity | Maverick was 10.10? So, you get to drop support when 12.04 ships? | 23:16 |
| infinity | Almost there! | 23:16 |
| GrueMaster | Yep. | 23:16 |
| TheMuso | lilstevie: Wow so you fixed the bug? | 23:21 |
| lilstevie | yep | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!