[00:13] grrr... I've just overwritten an image file trying to write to a SD card.... [00:57] is it possible to install gnome-classic on Oneric? [00:59] On arm? Not sure. If it is in the pool, then yes. [01:05] Unity was first in 11.04? or 10.10? [01:08] 10.10 on netbooks [01:08] IIRC [01:15] 10.10 yes. [01:45] I recently got a pandaboard [01:45] when I am trying to use the usb serial adapter my screen is complete garbled [01:46] I have the Prolific Technology pl2303 usb serial adapter [01:46] I have set the minicom settings from pandaboard side [01:46] I was wondering if anyone could help me fix this issue [01:47] krosswindz: I used to use those all the time (recently upgraded to an 8 port pci serial adapter for all my systems). I use screen and it works fine. "screen /dev/ttyUSB0 115200" should give you a serial console. [01:48] IME there are only one or two USB serial adapters in existence [01:48] Everything is just that rebranded [01:48] garbled might just indicate your baud rate is wrong [01:48] GrueMaster: I was using minicom [01:49] baud rate needs to be the same on both sides [01:49] GrueMaster: when I use screen I have the issue [01:49] minicom and sceren both work as client side; probably want getty on the server side [01:49] twb: I am setting baudrate as 115200 which is what is mentioned in the ubuntu website [01:49] That should be fine [01:49] When I use a different adapter it works fine for the same setting [01:49] Maybe that specific device is damaged [01:50] you mean the pl2303 might be damaged [01:50] device = that adapter, I mean, no the pandaboard [01:50] Right [01:50] thanks [01:50] I will see if I can get it replaced [01:50] They cost like $4 so just replace it [01:50] krosswindz: Are you plugging the 9 pin plug directly to the panda or are you using a cable/adapter in between? [01:51] GrueMaster: if he doesn't have a nullmodem cable it should just fail, right? i.e. not garbled [01:51] the 9 pin directly to the pandaaboard [01:52] when I using the tripplite keyspan usb serial adapter [01:52] it was all fine [01:52] i had borrowed that from my friend [01:52] if i switch to that same settings for minicom it is fine [01:53] Another thing to try is on the desktop side, type "sudo setserial /dev/ttyUSB0 base_baud 115200". [01:53] ok [01:53] Invalid flag: base_baud [01:54] Oops. baud_base (I had it reversed). [01:55] Cannot set serial info: Invalid argument [01:55] sudo setserial /dev/ttyUSB0 baud_base 115200 [01:55] thats the command I am using [01:57] http://pastebin.pandaboard.org/index.php/view/63324435 [01:57] that is the output of setserial -a [01:59] "Baud_base: 460800". That is the problem. [02:00] I am unable to switch it to 115200 [02:01] Try "sudo setserial /dev/ttyUSB0 port 0x0000 irq 0 uart 16654 baud_base 1152000" [02:03] Cannot set serial info: Invalid argument [02:03] hmmm. [02:03] sudo setserial /dev/ttyUSB0 uart 16654 baud_base 1152000 [02:03] sudo setserial /dev/ttyUSB0 uart 16654 baud_base 115200 [02:04] (somehow my copy/paste added a zero) [02:05] crap [02:05] sorry [02:05] i didnt see it [02:05] no go [02:05] same invalid argument error [02:05] You are running this on the host (usb) side, right? [02:06] yes this on the host side [02:06] my laptop [02:07] google isnt being helpful either :( [02:08] Try unplugging and plugging the usb serial adapter back in, then run setserial -a /dev/ttyUSB0 to see what it says. [02:11] its the same, http://pastebin.com/UCC17Ukx [02:11] Not sure why it is coming up with Baud_base: 460800 [02:11] Very odd. [02:11] I am leaning towards the fact that it could be a bad adapter/cable [02:12] Check dmesg to see what it says. [02:12] Also, when you plug it into the laptop, is it connected to the panda? Try unplugging from the panda. [02:12] Very possible. [02:12] http://pastebin.com/VkcUmEGP [02:12] ok [02:12] let me unplug from panda [02:13] its the same [02:13] i unplugged from panda, unplugged from laptop, then plugged to my laptop [02:13] ran setserial -a /dev/ttyUSB0 [02:13] the result is the same [02:14] Sounding like a bad cable. Nothing else I can suggest. [02:14] I am inclined towards the same [02:14] this sucks [02:15] i need to go borrow the cable again [02:15] thanks for your time GrueMaster [02:16] Sorry I couldn't help more. Good luck. [02:16] not a problem [02:17] at least one other person things its a bad cable [02:17] this was driving my nuts, I was thinking I was screwing up [02:19] Well, since it isn't directly in front of me, I can't actually diagnose that that isn't the problem. :P [02:19] I was wondering are there any documentation on setting up cross compile toolchain for arm on ubuntu [02:20] I want to rebuild my kernel, I was hoping I dont have to do it on the pandaboard [02:21] I think there is somewhere. Do a google search with " cross compile site:wiki.ubuntu.com". I've done it, but not for a kernel. [02:21] Also, I think the kernel build only takes 20 minutes if you are using a usb drive to build on. [02:22] I found the blueprint for it :p [02:27] http://manpages.ubuntu.com/manpages/hardy/man1/make-kpkg.1.html === dduffey is now known as dduffey_afk [02:29] Not sure if that will work, but worth a shot. You will need the arm compiler installed. [02:29] i will have to use it but only after I install the cross compile tool chain [04:14] I am seeing kernel oops on poweroff [04:14] http://pastebin.pandaboard.org/index.php/view/45552590 [04:14] thats the output from the serial console [04:33] Ouch [04:48] hmm... i had that effect too... but my board is a ti alpha board [04:52] mythos: ti doesn't make alpha architecture ;-P [04:52] twb, nice joke :o === doko_ is now known as doko === zyga_ is now known as zyga-xchat === Jack87 is now known as Jack87|Away === Quintasan_ is now known as Quintasan === dduffey_afk is now known as dduffey [15:40] jcrigby, I'd like to test your mx5 new kernels. Can you provide me with the most up-to-date ppa and what exactly to test - apart from it booting? [15:40] also a git repo would be helpful too in case I need to rebuild and change [16:04] GrueMaster, infinity rsalveti which is the ppa and kernel version to test for mx5? armhf , 3.0 or combined testing? [16:04] janimo: 1 sec [16:05] janimo: https://launchpad.net/~linaro-maintainers/+archive/kernel [16:05] argh, but it's just for oneiric there [16:05] let me check the other ppa [16:07] we moved the ppas around, let's wait jcrigby to answer that [16:07] rsalveti, the link you sent has precise armel mx5 [16:07] 3.1.1-10 [16:08] janimo: true! [16:08] janimo: that's probably best working one [16:08] is there a 3.2 that needs testing? I can wait for that too [16:08] janimo: 3.2 doesn't even boot [16:08] something we'll check at connect with the freescale guys [16:08] rsalveti, ok, I'll check that. jcrigby tested it I assume but you need another confirmation from Ubuntu-ARM? [16:09] janimo: exactly [16:09] ok. [16:10] janimo: the src package comes from https://github.com/jcrigby/packaged-linux-linaro-3.1-ci/commits/lt-mx5 [16:10] which is a merge from the lt source tree + packaging patches [16:10] and ubuntu sauce [16:10] rsalveti, thanks [16:12] Yea, we will have to rebuild those. No armhf kernels (which is the goal). [16:12] Do we not have netboot for mx5? [16:12] http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/ [16:13] No. [16:13] :( [16:13] ah because of univerese kernel [16:13] or such [16:13] ogra_: rsalveti: quick packaging questions... we have upgrade many packages in our PPA, but if we install the ubuntu-omap4-extras in a fresh install not all packages are installed at once, we need to make a dist-upgrade afterwards. is that normal? [16:13] Yea, something like that. [16:13] I quite liked the netboot experience on panda was hoping for a similar quick thing on mx5 [16:14] ndec: that will only happen if your meta package is requiring an specific version of a package [16:14] Get us a 3.2 kernel and the kernel team might be more lenient towards that. [16:14] as if it's just depending on the package name, it'll always grab the latest one available [16:14] XavB: is that the case ^^ [16:14] rsalveti: i think we explicitely conflicts/replaces the default ubuntu kernel so that it gets removed in favor of our 3.1 [16:15] janimo: jcrigby should know more about netboot for mx5 [16:15] but I think it should be easy to support [16:15] at least I know tftp should probably be working already [16:15] rsalveti: He was referring to netboot intstall. [16:16] (I call it netinstaller, but colin doesn't like that). [16:16] rsalveti: It's not a kernel issue, it's that we don't build d-i against universe kernels. [16:16] ndec: but as your kernel is newer anyway, all you need to do is to install your own kernel [16:16] oh, ok [16:16] ndec: guess the links will be in place after that, and flash-kernel will flash the latest installed one [16:17] the older one will still be installed, but don't thinkg that would be a problem [16:17] ndec: rsalveti: we are not requesting any specific version iirc, and if it was the case, the dist-upgrade would not work then. [16:17] rsalveti: we want to prevent the case where an upgrade from your kernel will replace ours [16:17] rsalveti: Hrm, looking at the haskell-src-exts build failure, I'm not sure this is a binutils issue (I need to test locally and see what processes are running to be sure, but there's no whining from ld) [16:18] rsalveti: So, it may still be a kernel issue. [16:18] rsalveti: as soon as you have two linux-image package version (2 abi versions) the last package installed is the winner [16:18] rsalveti: as XavB said, if both kernel are installed, since they don't have the same pkg name and ABI, a kernel upgrade from main archive will be installed and flashed [16:19] ndec: Perhaps a silly question, but is there any reason you can't work with ppisati to merge the bits you need into our kernel? [16:19] ok, so it can be problematically [16:19] ndec: Or are you building non-free stuff in? [16:19] infinity: yes, we are moving to 3.1 in oneiric... [16:19] but still, you just need to remove the kernel meta package [16:19] ndec: Oh, this is for oneiric. Kay. Not an issue for precise, then? [16:19] it's all free ;-) [16:19] not exactly, because of the abi [16:19] infinity: for P. we will move to 3.3 similarly. [16:19] yeah, removing it entirely will probably be the best thing to do [16:20] ndec: Are those kernels of yours supported with security updates and such? [16:21] no [16:21] So, enabling your PPA is effectively removing users' security support? :/ [16:21] but they have features that we can't backport with the resources we have, so instead of that we move forward. [16:22] yes, this is correct. we have added a note about that (debconf) so that users know about it [16:22] Why not just move forward with the development release instead, and leave the previous ones as they are? [16:22] ? [16:22] ie: Do what the rest of the distro does. :P [16:22] Freeze features at feature freeze, and then start targetting new stuff to the next release. [16:23] And that way, you can build on top of distro kernels instead of shipping your own. [16:23] we have to match different schedules all together... Ubuntu release cycle as well as our internal release cycles for TI customers that consume Ubuntu release from us. [16:23] it would be better to be aligned, but difficult [16:23] we build on top of linaro kernel (which we contribute to). [16:24] Sure, and we merge from the linaro tree as well, but we freeze at certain points. [16:24] for P. we in fact decided to support 3.3 only for MM. since some of our drivers were pushed into 3.3 mainline. [16:24] Which is a bit of a promise to the user, as well as people developing on the platform. [16:24] I'm not going to say your PPA can't do that. It's a PPA, it can do whatever you want. [16:24] we will support basic functionalities and X11 driver in 3.2, but we've moved all our dev to 3.3 [16:25] But it certainly cements positions on earlier conversations we've had about why PPAs can't be presented as installer options to end users. [16:25] agreed. [16:25] Cause removing the distro kernel in favor of an unsupported (and version mismatched, compared to other platforms) kernel is a bit nasty. [16:27] note that 3.2 from P. or 3.0 from O. just work without problems. [16:27] we just provide more features shoulld you decide to enable our PPA. [16:27] and i agree that this is the first time we push our kernel, but we really couldn't do without it this now. [16:27] Yeah, I realise that the distro kernels work, I use them. ;) [16:28] backporting all the PandaES support and power management to get 1.2Ghz from 3.1 to 3.0 was really waste of time on our end, especially because our internal TI releases were done on 3.1 [16:28] Just hoping your "NO SECURITY SUPPORT!!!111ELEVENTYONE" note is obvious enough to people. [16:28] And, sure, not many Pandas are internet facing or multi-user, but people should still be aware. [16:29] ndec: Sure, backporting isn't always the right answer. But we have a 6 months release schedule for a reason, hence my "just develop for the development release" point. [16:29] yeah, so it's either a nice media player with full HD playback *or* a very secure server with kernel security upgrades ;-) [16:29] ndec: If your PPA was developing for the development release instead of playing cacth-up on the released one, it would sort of solve most of this. [16:29] that brings another problem ;-) [16:30] for 10.10 we did work on the development release and struggled too much to make our internal stable with a dev release of Ubuntu... [16:30] so now we use the latest stable release instead of dev. i agree. [16:30] Was that before we actually had a sanely-maintained opam4 kernel? [16:31] Or was it fast-moving userspace changes that were killing you? [16:31] ndec: To be fair, the hardware wasn't stable either during 10.10 development. [16:31] the problem was not kernel, but archives. [16:31] the fact that archive was different everyday was painful since we couldn't make stable (reproducible) releases out of it. [16:31] ndec: Well, sure, cutting released images from it is often a no-go. [16:32] ndec: The general idea is to do feature development while we're doing the same, and then as it stabilises, ship. [16:32] ndec: I guess if you have customer obligations to ship Feature X "right effin' now" on top of a stable distro, you don't have much choice but to do what you're doing right now. [16:33] yeah... two contradicting goals ;-) [16:33] ndec: But most people seem to figure out a way to communicate why that's insanity, and do it more sanely. You could always try. ;) [16:34] ok.. i wish we could continue the discussion, but i need to go. will catch up later. [16:34] ndec: Later. ;) [16:39] infinity, my 1hr estimation was for the qtwebkit build. It is now 70 min into linking with 1.7G of virtmem used accordint to top. IIRC last time it was simply OOM-killed ld did not get around to complain either [16:41] janimo: Yeah, my 10m may have been a bit generous. I was always multitasking before when testing, not watching it. ;) [16:42] janimo: 72m... So... Uhm... It's 10 minutes, if you ignore the extra hour! [16:42] infinity, also some drugs are known to make time fly ;) [16:43] hmm it did not yet finish here after 75 min, (debuild -us -uc -ns so some overhead above just the gcc invocation) [16:44] real 72m21.672 [16:44] ok, should be finishing here up as well soon then [16:45] * janimo wonders if some local proxy and url rewriting could convince netboot to work with kernels that are in universe only [16:45] sounds boring though [16:46] why does D-I not have an option off by default to allow using universe? [16:47] How would that solve anything? [16:47] This is on the buildds we're talking here, not in your home. [16:47] As in, building d-i generates those images, and d-i (in main) doesn't build against universe. [16:48] infinity, oh I mean only for devel use, if I wanted to have a netboot image on the board [16:48] Doing it yourself isn't hard at all. [16:48] is there a doc ? [16:48] No. :P [16:49] Documenting d-i would take about as long as rewriting it. And reading the docs would take almost as long as reading all the source for all the components. [16:49] So, uhm. It's the ultimate "use the source" example. [16:49] that the fact it is easy is not very relevant :) [16:49] after earing so many things about d-i, this advice make me uneasy [16:50] hearing [16:50] Most people who whine about d-i just like whining. [16:50] So, erm. Hrm. [16:51] janimo / rsalveti: Maybe the 3/1 split thing isn't actually fixed. Or, not completely. [16:51] Sure, the simple testcase passes. [16:51] And when watching swap usage, I see it go up to ~2G, which seems reasonable. [16:52] But I sort of forgot my system was eating nearly 1G before g++ was run. [16:52] So, ld's probably only using about 2G there. [16:52] I need to monitor this more sanely. [16:52] my build is still not over after 1h25m. I wonder is my swap is that much slower - external USB disk [16:53] 1Ghz panda [16:53] janimo: Are you sure you don't have some swap on SD too? [16:53] janimo: If it's a default install, you have swap on SD, which it will hit before disk. [16:54] cat /proc/swaps [16:54] it is a netboot install directly to the USB disk, only uboot+kernel are (hopefully) on SD [16:54] Oh, hrm. Then I dunno. [16:54] once ld lets me have a scheduler slice I'll check that [16:54] Oh wait, but you said your build was a full debuild? [16:54] I was just re-running the g++ call. [16:55] debuild -nc reached that in less than a couple minutes I'd say. Now at 1.8G virtmem [16:56] Well, it should die soon. [16:56] debuild -nc is very useful, I only found out about it at last rally. from you incidentally [16:56] And if it does die around ~2G, I now want to know why the testcase works. [16:57] or I may have tried it earlier on a broken package and given up on hoping it does what it is meant to do [16:58] infinity, is this related to the top-down MMAP bug thing or some other mmap issue? [16:58] janimo: It's the same (the only?) mmap thing we've been talking about for the last six months. [16:59] I was only aware of one - for which we last month did SRUs [16:59] not being able to alloc past 2G or something [16:59] Yeah, that one. [16:59] ok [16:59] And the testcase now passes. [16:59] But perhaps the testcase is broken. :P [17:00] I have other tests that were broken prior to the fix that now work. [17:00] For the same reason. [17:00] So in my SRU testing, I am hitting this from multiple angles. [17:01] Okay, for "passes", I mean "the testcase almost passes". [17:01] It hits 2925MB (not 2999, as it does on x86), but close enough. [17:02] Almost? didn't know there were multiple levels of passing. [17:02] GrueMaster: From my POV, "close to 3G" beats "only 2G". ;) [17:02] Ah. [17:02] (And it was passing on the SRU kernels, it's the precise kernel where it's only 2925) [17:02] But in all cases, the qtwebkit-source build fails. [17:05] infinity: Do you want to try building that package on my server? It has 4G physical memory, SATA (16G SSD), 1GE, and ipv6. [17:05] (and it is idle at the moment). [17:05] GrueMaster: Erm. How's that help me? [17:06] Speed. [17:06] (Faster to fail). [17:06] GrueMaster: It's already failed here. Countless times. [17:11] GrueMaster, does that server have precise or a precise chroot? [17:11] janimo: https://code.launchpad.net/~linaro-maintainers/+archive/kernel/+recipebuild/167772 [17:11] would be interesting to see how fast it fails there [17:11] preciseHF. [17:11] janimo, that is the latest mx5 3.1 build [17:11] but it is oneiric [17:11] janimo: I'm on it already. [17:12] infinity, ok [17:12] janimo: qtwebkit, that is. [17:12] yes [17:12] janimo: jcrigby is all yours. :P [17:12] janimo, but should be identical [17:13] jcrigby, I understand the testing is for inclusion in precise, so I guess the precise/ppa should be a better choice? Unless they're exactly the same of course [17:13] janimo: They won't be exactly the same, even if the source is, due to toolchain changes. [17:13] We really do need to test precise kernels built on precise. :P [17:14] so the PPA it is then [17:15] infinity, janimo: if you want to try that out while I work on our source upload recipe issue then go for it, otherwise I'll ping you when I have a precise version [17:15] janimo, or actually let me look for an older precise armhf build [17:16] Is this not ok ? https://launchpad.net/~linaro-maintainers/+archive/kernel/+packages?field.name_filter=&field.status_filter=published&field.series_filter=precise [17:16] the one rsalveti mentioned above [17:16] https://code.launchpad.net/~linaro-maintainers/+archive/kernel/+build/3126577 [17:16] I will test armel first [17:17] kernel images should be the same for armel and armhf right? [17:17] yes should be unless there is a bug in the toolchain [17:17] janimo: They should bit-for-bit identical, even. [17:17] because the kernel uses no floating point [17:17] janimo: Except for the debian packae. [17:18] janimo, the testing I did was just with a minimal linaro rootfs, booted [17:19] and I also saw console on vga, did not test with hdmi adapter [17:22] I don't own the HDMI adapter. [17:22] GrueMaster does, though. [17:23] I think hdmi requires a u-boot parameter. I have the adapter, but haven't had time to test it. [17:23] Yeah, it requires changing the command line. [17:23] It's super user-friendly. [17:24] Unless either Freescale or Linaro have made the displays actually auto-detect and auto-switch in 3.x? [17:27] That would be sweet. [17:27] But would probably require the closed source bits. [18:00] infinity, two 4G swap files in / (USB disk), still linking after 2:30h [18:00] no idea where the difference can come from === cmagina_ is now known as cmagina-lunch [18:44] janimo: That's certainly odd. [18:44] janimo: What's the memory usage at on your 2.5h link? [18:44] * janimo goes checking [18:45] oh it stopped [18:45] last time it was 1.8G did not check after that [18:46] infinity, real 197m29.862s user 1m58.063s sys 1m30.719s [18:48] Killed process 19240 (ld) total-vm:840480kB, anon-rss:838092kB, file-rss:48kB [19:13] Under the current ubuntu 12.04 arm version i get this when trying to use alsa [19:14] ALSA lib main.c:260:(execute_sequence) unable to open ctl device 'hw:Panda' [19:14] though when i do listcards i see 0: Panda [19:14] (this was working under 11.10) [19:15] im guessing it has something to do with /usr/share/alsa/ucm/Panda/ the files there [19:15] pbuckley: Known. See bug 925069 [19:15] Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,New] https://launchpad.net/bugs/925069 [19:15] ah thanks [19:16] It might, haven't had a chance to really look into it. Just discovered it yesterday with milestone testing. [19:17] im also getting the same dmesg dump fyi thats in the bug [19:18] also just want to say i can't believe the performance improvement in 12.04 over 11.10, its like an entirely new machine [19:30] pbuckley: Are you using armel or armhf build of 12.04? [19:30] ogra_: rsalveti: I am trying to copy packages (without rebuild) from ppa ti-omap-private to release ppa and I am facing "timeout issue"... Error ID: OOPS-93333df9d8f15a5bfb041f2c181e8b10... Any idea? [19:30] https://lp-oops.canonical.com/oops.py/?oopsid=93333df9d8f15a5bfb041f2c181e8b10 [19:30] hello all -- got a quick ?? I need net_tstamp.h on 10.04. can I get this somewhere? or do I take what in kernel.org and drop in? [19:31] armel, should i be using armhf? [19:31] orbarron: For armel? What platform? [19:32] pbuckley: Yes, please. We are trying to shift to armhf, and the more testing, the better. [19:32] It should also give a slight boost in performance. [19:32] well -- am working on 1588 on a DM8148 -- and testing this on a host + device platform. [19:32] do i need to do a fresh install or can i just do sed -i 's/armel/armhf/g' /etc/apt/sources.list [19:33] pbuckley: I don't think that is recommended. Fresh install would be better. [19:33] ok [19:33] Kind of like s/i386/amd64 on intel HW. [19:33] ah ok [19:33] Not recommended. [19:33] neat [19:34] orbarron: Where is that file normally located? Is it part of the kernel headers? [19:34] yes [19:35] And I assume you have a custom kernel. I would recommend using it from your kernel source tree. [19:36] well -- I need this on my host.. but not sure if I could drop this in the proper location or if there was a package I could download -- problem is Im not sure what impact it might have on my existing headers.... [19:48] orbarron: It's in linux-libc-dev [19:48] orbarron: Which you'd have installed if you install build-essential. [19:52] got that -- but no net_tstamp.h -- this might be based on a newer kernel -- Im on 2.6.32-38 and checking into this atm [19:53] orbarron: Oh, it wasn't in linux-libc-dev in lucid, no. [19:53] orbarron: Only newer releases. [19:53] ahh that is what I figured... [19:54] hmm -- can I pull in the newer headers or will this mess other things? [19:55] If it's fairly self-contained, you can pull just that one header, but if it relies on other interfaces having changed, you're a bit out of luck. [19:56] does anyone know of any drivers available for usb wifi sticks? [19:57] That's pretty non-specific. [19:57] Erm, most x86 drivers should also be on the arm images. [19:57] But I can tell you that most any USB WiFi stick that works on x86 will also work on ARM. [19:57] Our distro kernels build everything they can, unless it breaks. [19:57] kk [20:00] I've just plugged in a usb wifi stick and was expecting iwconfig to recognise it straight away [20:02] dioxin: Did the system load a module on plugin? That's the first thing to check. [20:02] I'm just trying to figure stuff like that out [20:03] thanks infinity [20:04] Gruemaster: do I need to output dmesg to find that ? [20:04] yes. [20:05] what text would tell me a module is loaded, I dont see anything obvious [20:05] XavB: this timout issue is very annoying [20:05] XavB: happens from time to time [20:05] XavB: try copying just one package at a time [20:06] dioxin: Does the device show up in lsusb? [20:06] yes [20:07] You should see a kernel message in dmesg showing the device being plugged in. [20:07] http://pastebin.com/6W4rcCGR [20:07] think I see that in there [20:10] dioxin: Could just be some USB IDs missing from the correct atheros driver. [20:11] infinity: is there anyway to check if I have the driver isntalled? [20:12] I see no messages there from a driver being loaded. [20:12] Which means there was no ID->driver mapping found for that specific device. === cmagina-lunch is now known as cmagina [20:20] any updates on the prime? [20:25] infinity: I tried to find the module in modprobe but its not there [20:25] dioxin: First off, does the usb wifi device work on x86 Linux? [20:26] yes [20:26] ath9k is the driver [20:28] And you're using the same version of Ubuntu on ARM? [20:29] ath9k is definitely there on omap4 in precise. [20:29] Not sure about past releases. [20:29] I'm on Onerioc on both [20:29] ubuntu on both [20:31] sigh. # CONFIG_ATH9K is not set [20:31]