[10:49] <apw> smb_tp, your aspire is that 32 bit or 64 ibt?
[10:49] <apw> and indeed can it be 64 bit?  i suspect not?
[10:50] <smb_tp> hm good question. lemme look
[10:50] <apw> its lm in the cpu flags i think which says 64 bit capable
[10:51] <smb_tp> apw, is 32bit
[10:51] <apw> and only?
[10:53] <smb_tp> I see no capable, but neither do I on a 64bit capable
[10:54] <apw> i'll assume these are 32 bit only, saves me some build time
[10:55] <apw> and as you are my likely test kernel consumer it makes sense to make what you need :)
[10:55] <smb_tp> hehe, yeah
[11:38] <apw> smb_tp, could you have a boot of the kernels here:
[11:38] <apw> http://people.ubuntu.com/~apw/lp319825-jaunty/
[11:39] <apw> this should produce some debug in your dmesg every second
[11:39] <apw> and try toggling the rfkill button as well
[12:24] <nightwish> sorry, we have to perform emergency maintenance on this host so it will go down now. i hope we'll be back within the next 10 minutes
[13:09] <smb_tp> apw, your kernel installed msg every second: status<S> state<0>
[13:10] <smb_tp> wiggeling the killswitch seem like no effect
[13:10] <smb_tp> No wireless
[13:11] <apw> and no change to the data reported ?
[13:11] <smb_tp> no change visible
[13:11] <apw> hrm
[13:12] <apw> does the kill switch do anything visible, toggle leds etc?
[13:13] <apw> smb_tp, ^^
[13:13] <smb_tp> just playing. no leds
[13:13] <smb_tp> last change on unload status<F>
[13:14] <smb_tp> using killswitch then
[13:14] <smb_tp> wlan1 direct probe timed out
[13:14] <smb_tp> and wiggeling again
[13:14] <smb_tp> ap is found again
[13:15] <smb_tp> but no led indicator
[13:15] <apw> so in summary all APW: lines have S 0 on them except the one on unload
[13:16] <smb_tp> correct
[13:16] <apw> that is officially poor
[13:17] <smb_tp> or not exactly correct. First one hat status S state 1
[13:17] <smb_tp> but that was set
[13:18] <smb_tp> the last one with status F was also a set
[13:18] <smb_tp> all other msgs were update
[13:27] <apw> ok makes sense
[13:27] <apw> smb_tp, whats you machine lshal | grep machine say
[13:28] <smb_tp> system.kernel.machine = 'i386' (string)
[13:28] <smb_tp> err
[13:28] <smb_tp> i686
[13:29] <apw>  lshal | grep system.hardware
[13:30] <apw> smb_tp, ^^
[13:31] <smb_tp> peace, my multitasking is not as good
[13:31] <apw> heheh
[13:31] <smb_tp> primary_video.product = 10158 (0x27aw)
[13:32] <smb_tp> primary_video.vendor = 32902 (0x8086)
[13:32] <smb_tp> product = A0A110
[13:32] <smb_tp> vendor Acer
[13:32] <smb_tp> version 1
[13:32] <smb_tp> and a serial and uuid I am too lazy to type
[13:34] <apw> so product is _just_ A0A110
[13:35] <smb_tp> yes
[13:41] <apw> smb_tp, would it be reasonable to say that your kill switch works fine without the acer-wmi loaded
[13:41] <smb_tp> yes, I would say so
[13:41] <apw> i am wondering if basically we don't need rfkill support on some machines
[13:42] <apw> and perhaps we need a quirk for that in here
[13:42] <smb_tp> sounds like an option. the wmi support seems do be more hindering that supporting
[13:43] <apw> yeah, will spin some more debug and see what we can find out
[13:43] <smb_tp> ok, sure. waiting for next kernel :)
[13:45] <apw> this meeting thing is pretty soon isn't it
[13:46] <smb_tp> yeah, right
[13:46] <smb_tp> too soon to have final results but we are on it
[14:05] <Kano> hi, why is the aufs compile fix for 2.6.29 not in git?
[15:54] <amitk> bradF: did you see junjiro's comments to your aufs patch?
[16:08] <bradF> amitk: yes, I haven't looked at his patches yet
[16:09] <bradF> amitk: i've been concentrating on getting my own kernel on the babbage board so I can start bugshooting that oops
[16:16] <cooloney> bradF, have you boot up your own kernel on babbage?
[16:16] <bradF> cooloney: no, am close, fighting with minicom right now
[16:17] <cooloney> bradF, cool. do you know how to replace the kernel on SD card?
[16:18] <bradF> cooloney: I believe so, I've looked at the wiki page https://arm.wiki.canonical.com/Home/Freescale/Babbage
[16:18] <amitk> bradF: you can also use 'screen /dev/USBDEV 115200' 
[16:18] <cooloney> bradF, thx
[16:18] <bradF> amitk: screen is new to me, i've used minicom in the past
[16:18] <bradF> amitk: how do you do a file transfer in screen?
[16:19] <amitk> bradF: no, I just use the sb/sx binaries
[16:19] <amitk> bradF: but minicom works too
[16:20] <bradF> amitk: If I understand you, you use screen to break into redboot
[16:20] <amitk> I use screen a lot to keep sessions available through remote login
[16:20] <bradF> amitk: then get out of screen and start the ymodem download
[16:21] <bradF> amitk: then get back into screen to copy the image to the SD card
[16:21] <bradF> amitk: is that the steps you follow?
[16:21] <amitk> bradF: umm, no. Ctrl-A :exec <sb cmdline>
[16:22] <bradF> amitk: will give that a try
[16:24] <cooloney> amitk, bradF is it possible to load kernel to babbage in redboot via ethernet tftp?
[16:24] <bradF> cooloney: I think that should be possible, I was just using serial because that is know to work
[16:24] <amitk> cooloney: lool might know about it. The ethernet driver is pretty crappy
[16:25] <bradF> amitk: the redboot ethernet driver is crappy?
[16:25] <lool> bradF: mcasadevall told us today how it works
[16:25] <mcasadevall> No, works fine.
[16:25] <lool> mcasadevall says that it will only work if it gets IP via bootp
[16:25] <amitk> bradF: ohh... I wasn't thinking. The mx51 ethernet driver is crappy
[16:25] <lool> or if it's set in config
[16:25] <mcasadevall> Or manually config with fconfig
[16:26]  * mcasadevall notes its the kernel driver which is a pile of $#@! in 28
[16:26] <cooloney> great
[16:27] <bradF> i thought I'd used tftp on a previous project but it was a while ago
[16:27] <bradF> that was with redboot
[16:27] <amitk> if you do use it, please add it to the wiki
[16:27] <amitk> would be a lot faster than serial
[16:28] <bradF> amitk: will do
[16:29]  * mcasadevall does use it
[16:30] <cooloney> thanks guys, i might try it this weekend.
[16:30] <cooloney> i have to go to sleep, have a nice weekend guys. -:))
[16:31] <bradF> cooloney: bye, maybe see you this weekend, will look for you
[16:31] <amitk> cooloney: have a good weekend
[19:13] <ernstp> IntuitiveNipple: any new thought on bug #343919 ? :-)
[19:13] <ubot3> Malone bug 343919 in linux "Nvidia MCP67 AHCI ata timeout exception with data loss" [Medium,In progress] https://launchpad.net/bugs/343919
[19:15] <IntuitiveNipple> No, not had chance to look at it, got several other issues to investigate currently.
[20:35] <bradF> amitk: still around?
[21:33] <hallyn> hmm, i'm surprised - ubuntu-jaunty.git has no btrfs?