[06:48] <ppisati> moin
=== smb` is now known as smb
[07:19] <smb> morning
=== deffrag_ is now known as deffrag
[07:28] <ericm|ubuntu> ppisati, what's the solution for irq_to_gpio() being messed up in 3.2 kernel, which may have impact on several ARM flavours?
[07:47] <ppisati> ericm|ubuntu: messed?
[07:47] <ppisati> ericm|ubuntu: IIRC every platform provides its own implemantation
=== dholbach_ is now known as dholbach
[08:25] <dholbach> hey
[08:25] <dholbach> how do I debug a kernel which crashed (no magic sysrq, had to turn off and back on again) - nothing in /var/log/syslog?
[08:26] <ppisati> smb: apw if off today, right?
[08:26] <smb> ppisati, and tomorrow
[08:26] <smb> dholbach, not very much
[08:26] <dholbach> that sucks :-(
[08:26] <smb> dholbach, You had flashing caps (if there is still a led for it)?
[08:27] <dholbach> nope, it didn't flash
[08:28] <smb> So it might not have gone to the crash handler. Did you try to ping/ssh into it and it was dead, too?
[08:29] <dholbach> no, I didn't have another machine to ping it handy
[08:29] <dholbach> but changing to the console, magic sysrq and ctrl-alt-del weren't available
[08:30] <smb> Hm, ok. Wait you were able to change to the console?
[08:30] <dholbach> no
[08:30] <dholbach> none of the above worked
[08:30] <dholbach> I had to power off and back on again
[08:31] <smb> dholbach, ok, so it still could be a lock up which affected the input handler as well.
[08:31] <dholbach> right, I guess so
[08:32] <smb> But the problem is without anything else it could be that or something else. Just not possible to say anything for sure... :/
[08:34] <smb> dholbach, So the only thing you can do is trying to observe whether it repeats and if it does whether there is any pattern to it.
[08:34] <dholbach> ok, let's say I have a machine to ssh/ping it with next time
[08:34] <dholbach> what are the next steps, if I 1) can ssh into it, 2) can't
[08:35] <dholbach> it doesn't happen very often, so bisecting kernels will be hard to do
[08:35] <dholbach> is there any debug information I can try to dig out?
[08:35] <dholbach> (this time I didn't do anything out of the ordinary: IRC, some terminals)
[08:36] <smb> If it pings, it is at least alive on a low level. If ssh succeeds its a lockup somewhere in X/input, ssh responding but login not succeeded, may point to a low-memory issue
[08:37] <dholbach> low memory meaning I ran out of memory or that there's a bug in memory handling somewhere?
[08:37] <smb> right
[08:37] <dholbach> I can't imagine I ran out of memory this time
[08:38] <dholbach> but I'll check the next time
[08:38] <dholbach> is there a way to have a kernel with more debug output or something?
[08:38] <smb> That was more related to the case that you can ssh but the login does not work. 
[08:39] <dholbach> ah ok
[08:39] <smb> The problem with that kind of bug is that if shutting down is the only solution then more debug does not help either
[08:39] <dholbach> at least some of it might have gone to /var/log/syslog, no?
[08:39] <smb> You can boot with "debug" (instead of quiet) in the kernel commandline from grub
[08:39] <dholbach> alright, will do
[08:40] <smb> Most of the times if there is a hard crash, writing to a filesystem stops before that (its not synchronous)
[08:42] <dholbach> ok
[08:43] <ericm|ubuntu> ppisati, omap provides one?
[08:44] <dholbach> thanks smb
[08:44] <dholbach> I'll see what I can dig out
[08:45] <ericm|ubuntu> ppisati, git grep 'irq_to_gpio' arch/arm/mach-omap2/ shows no result
[08:45] <smb> dholbach, Welcome. The primary step right now would be to find out whether it was really a crash (able to ping/ssh or not). The next steps would then depend on that outcome
[08:45]  * dholbach nods
[09:08] <ppisati> ericm|ubuntu: sorry, omap3 in master is busted... :P
[09:08] <ericm|ubuntu> ppisati, which ARM flavour is not busted so far?
[09:08] <ppisati> ericm|ubuntu: err.. i think you are right, and i'm pretty sure i hit this in the omap4 branch too
[09:08] <ppisati> ericm|ubuntu: :)
[09:09] <ericm|ubuntu> ppisati, I think the issue could have been fixed in Q (3.4) by the way, we may have to identifiy and backport them
[09:11] <ppisati> ericm|ubuntu: uhm
[09:13] <ppisati> ericm|ubuntu: drivers/gpio/gpio-ep93xx.c:#define irq_to_gpio(irq)     ((irq) - gpio_to_irq(0))
[09:13] <ppisati> ericm|ubuntu: and gpio_to_irq() is defined for mach-omap2/$board
[09:13] <ericm|ubuntu> ppisati, that's actually not a correct fix
[09:13] <ericm|ubuntu> ppisati, but not irq_to_gpio()
[09:13] <ericm|ubuntu> ppisati, all those drivers making use of irq_to_gpio() now failed in 3.2
[09:14] <ppisati> ericm|ubuntu: do you have the commit where they retired irq_to_gpio for omap?
[09:15] <ericm|ubuntu> ppisati, I think it's a global one, removing all the specific APIs to asm-generic
[09:15] <ericm|ubuntu> ppisati, wait
[09:15] <ericm|ubuntu> ppisati, 7563bbf gpiolib/arches: Centralise bolierplate asm/gpio.h
[09:16] <ppisati> and i just found out another case where having vfat + nls_iso8859_1 builtin is mandatory...
[09:19] <ericm|ubuntu> ppisati, actually when doing the config comparison, I came up with the table - https://wiki.canonical.com/EricMiao/Highbank/ConfigReview/Ubuntu-3.2.0-25.40/5/PurpleLinesClassified
[09:19] <ericm|ubuntu> ppisati, where we do have many inconsistent config options between ARM flavours and X86 ones
[09:20] <ericm|ubuntu> ppisati, some are for no obvious reason
[09:20] <ppisati> ericm|ubuntu: i know, it's on my todo list
[09:20] <ericm|ubuntu> ppisati, ok - just let know what I can help on that
[09:20] <ppisati> ericm|ubuntu: https://wiki.ubuntu.com/Kernel/Dev/pisosandbox
[09:20] <ppisati> ericm|ubuntu: but this one is only for omap4
[09:20] <ericm|ubuntu> ppisati, and btw - apw is working on config alignment between flavours
[09:21] <ppisati> ericm|ubuntu: yep
[09:42] <janimo> apw, do you know if adjustments were made to kernel package builds to cope with some headers moving to multiarch dirs? I get sys/types.h not found when building scripts/basic/fixdep in the armadaxp kernel
[09:49] <orated> Hey ppisati
[09:51] <orated> I'm using Beagleboard B4 and for getting ethernet working, a usb-ethernet adapter is connected. I'm not able to get ethernet working on it. Is there any specific kernel module required to be loaded for it to work? My connection setup - Both beaglebaord and USB hub are externally powered with 5V supply. USB ethernet adapter connected to the HUB
[09:53] <ppisati> orated: if the adapter is supported, the module should be autoloaded
[09:53] <ppisati> orated: have you tried this adapter with another pc running ubuntu?
[09:53] <orated> Yes
[09:53] <orated> Hold on, I'll give you the details
[09:53] <ppisati> orated: does it work? which module does it use?
[09:54] <orated> ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter
[09:54] <orated> 						driver:dm9601(configuration: autonegotiation=on broadcast=yes driver=dm9601 driverversion=22-Aug-2005 duplex=full firmware=Davicom DM9601 USB Ethernet ip=192.168.10.110 link=yes multicast=yes port=MII speed=100Mbit/s)
[09:54] <orated> Same setup on host system with the hub
[09:54] <ogra_> do you see it with lsusb 
[09:55] <ogra_> ?
[09:55] <ogra_> (on the beagle that is)
[09:55] <ogra_> note that nobody in the ubuntu dev team has tested on beage B models in years (they dont fulfill the minimal reqs.we usually only test XM)
[09:56] <orated> On the beagle, no 
[09:56] <orated> ah
[09:56] <ogra_> a server install should still be possible on the rev. B though
[09:56] <orated> Could you guide me on that?
[09:57] <ogra_> (dont expect a great experience with 600MHz and 128MB though)
[09:57] <orated> I only need network connection to install and update packages
[09:59] <ogra_> hmm, https://wiki.ubuntu.com/ARM/Server/Install used to have a section for omap3 too, seems it is gone, talk to #ubuntu-server, seems they removed that section (especially all the special setup you hgave to do with old beagles)
[10:00] <orated> I tried sudo dhclient usb0 and then ifconfig usb0 192.168.1.5 netmask 255.255.255.0 and they ran without errors
[10:00] <orated> ok, I'll try
[10:01] <ogra_> well, does a plain ifconfig show the usb0 device ?
[10:01] <orated> yes
[10:02] <ogra_> so your network should work then after you set up proper routing
[10:02] <orated> proper routing, like? I'm new to nwtwork related tasks
[10:03] <ogra_> look on your desktop computer (if its in the same network) with "route -n" what the default GW points to 
[10:03] <orated> Yes, in the same network
[10:03] <ogra_> then use "sudo route add efault GW <IP you found above>"
[10:03] <ogra_> *default
[10:04] <ogra_> probably gw needs to be non capitalized ... 
[10:04]  * ogra_ doesnt use this very often
[10:04] <ogra_> after that try to ping the gateway IP
[10:12] <orated> ogra_: http://paste.ubuntu.com/1022830/
[10:12] <orated> Is that correct?
[10:14] <ogra_> well, are you sure a plain ifconfig (without options) shows usb0 on the beagle ? also, if you use dhclient you dont need to set the IP manually with ifconfig afterwards
[10:14] <ogra_> (and if the dhclient command worked you shouldnt need to set the route either)
[10:16] <orated> ogra_: Yes, http://paste.ubuntu.com/1022834/
[10:16] <orated> There are some garbage character coming on the serial terminal though
[10:17] <ogra_> looks all fine, you should be able to ping the GW right after the dhclient command, weird that you cant
[10:17] <orated> Alright, now I would like to know if there is any need to load module like g_ether ?
[10:18] <ogra_> no, g_ether is for USB->USB networking through an USB cable 
[10:18] <orated> Ethernet gadget, ok
[10:18] <ogra_> (it emulates the ethernet connection between two USB devices)
[10:18] <orated> Then is there any module required for usb-ethernet adapter?
[10:18] <ogra_> no
[10:19] <ogra_> not apart from the one that brings it up as usb0
[10:19] <ogra_> which apparently is already loaded on your beagle (else ifconfig wouldnt see a device)
[10:20] <ogra_> so there might be a bug with that driver or a wrong/outdated firmware etc ... i'll leave you with ppisati to debug that part :) 
[10:20] <orated> In desktop with USB hub it uses driver:dm9601 and without usb hub, its not getting connected. So in beagleboard, is there any module to load to be use that driver?
[10:20] <orated> hmm, thanks for your help :)
[10:21] <ppisati> orated: i bet you need the dm9601 kernel module
[10:21] <ogra_> well, if ifconfig sees usb0 that driver should be in use already 
[10:21] <ogra_> lsmod|grep dm9601
[10:21] <ogra_> that should show the module being loaded on the beagle 
[10:21] <ppisati> ogra_: isn't it the usb network?
[10:22] <orated> no, nothing ogra_
[10:22] <ppisati> orated: we had the usb0 as a nic till maverick
[10:22] <ppisati> orated: sudo modprobe dm9601
[10:22] <ppisati> orated: which kernel are you using?
[10:22] <ogra_> (and which image did you install)
[10:22] <orated> omap 3.2.17-11 #1 SMP Tue May 15 12:16:43 UTC 2012 armv7l
[10:23] <ppisati> orated: find /lib/modules/`uname -r` -name \*9601\*
[10:26] <orated> one moment please
[10:28] <orated> ppisati: /lib?mdules?3.217-11?kernel?drivers?net?usb?dm9601.k
[10:28] <orated> There are still garbage issues, I restarted for the same
[10:28] <orated> Maybe its the cable or loose connection
[10:28] <ppisati> orated: ok, then you have the module
[10:28] <ppisati> sudo modprobe dm9601
[10:28] <orated> Yes, I did that
[10:29] <ppisati> uhm
[10:29] <ppisati> can you bypass the usb hub>
[10:29] <ppisati> ?
[10:29] <orated> And its listed now in lsmod
[10:29] <orated> bypass as in?
[10:29] <ppisati> and you didn't get anything in console, right?
[10:30] <orated> nope, just the prompt after the command
[10:30] <ppisati> ack
[10:30] <ppisati> then unplug it from the usb hub and attach it directly to the board
[10:30] <orated> One moment, I think the adapter got disconnected
[10:31] <orated> Yes, restarting the whole setup. .. One minute
=== orated_ is now known as orated
[10:44] <orated> ppisati:  Regarding OTG port on BB, I've connected a OTB to USB  which is then connected to USB female to female adapter and then it goes to USB hub or USB storage device/usb-ethernet. The problem of connecting it directly without the hub is that, it doesn't get powered up. ..
[10:45] <orated> Regarding the USB hub, its Belkin self powered 4 ports USB2.0 if that helps
[10:47] <ppisati> orated: well, the problem is that your board doesn't sense any "usb thing" attached to it wrt to your usb nic
[10:47] <orated> And I tried it again with the hub, its still outputting nothing on sudo modprobe dm9601, falling back to prompt
[10:47] <ppisati> orated: so we need to get rid of the usb hub
[10:47] <orated> It requires to be independently powered
[10:47] <ppisati> orated: wait
[10:48] <ppisati> orated: how do you power the board?
[10:48] <orated> Also , other storage devices comes up with same behaviour. The BB is powered using 5V adapter
[10:48] <orated> And the hub is also powered using another 5V adapter
[10:49] <orated> BTW I've noticed that if I connect any storage device to the hub, it doesn't show up in /media
[10:49] <ppisati> ok, the if the board is powered indipendently, why can't you unplug the usb hub and attached the usb nic to the board?
[10:49] <ppisati> *attach
[10:51] <orated> Oh, you wanted to know if OTG is unused or not. Yes, I can unplug the usb nic from hub and conenct to board but its not getting its not getting sufficient power to start it. There is a LED on the nic which glows when RJ45 is connected
[10:51] <orated> Anyway, I'll try connecting it directly again
[10:52] <orated> Nic removed from the hub, connected to board, no led on nic
[10:54] <ppisati> any msg on console?
[10:54] <ppisati> dmesg?
[10:54] <orated> No, the serial console hanged
[10:54] <orated> Its not accepting any input. Hold on please
[11:01] <orated> ppisati: Back, no no change in dmesg on connecting/disconnecting nic directly to the board
[11:04] <orated> ppisati: Do you think its due BB being not sufficiently powered?
[11:04] <ppisati> orated: could be
[11:05] <ppisati> orated: i've a dm9601 adapter, let me try it with my bbxm
[11:05] <orated> ppisati: But then what's the problem when USB hub is used?
[11:06] <orated> ppisati: And secondly, I don't understand why usb storeage devices don
[11:06] <orated> n't show up in lsusb//media when they are connected to the hub
[11:06] <orated> storage*
[11:16] <orated> Is 12.04 LTS server image supported for BB or should I try 11.10?
[11:17] <ogra_> as i said before, we all only test on beagle Xm since it is the only beagle that fulfills the minimal requirements for ubuntu
[11:18] <ogra_> so getting it to run on a beagle rev. B is really a matter of luck
[11:20] <jMCg> I got 10.10 in a KVM in an init=bash: http://dpaste.com/755097/ -- can someone help me debug and make it boot?
[11:20] <jMCg> s/10.10/10.04/
[11:22] <ogra_> seems to boot just fine 
[11:23] <ogra_> (for booting with init=bash at least)
[11:26] <jMCg> ogra_: that's true, but when I take that away, it chokes. I've pasted --verbose and --debug in this channel, let me reproduce those.
[11:27] <jMCg> http://sprunge.us/iGaU << --debug
[11:29] <orated> ppisati: Is dm9601 adapter working for you in BB xm?
[11:37] <orated> Unfortunately, xm is on back order here and can be available only after a month
[11:52] <ppisati> [ 3757.129302] usb 1-2.2: new full-speed USB device number 8 using ehci-omap
[11:52] <ppisati> [ 3757.365447] dm9601 1-2.2:1.0: eth1: register 'dm9601' at usb-ehci-omap.0-2.2, Davicom DM9601 USB Ethernet, 00:10:13:50:a3:43
[11:52] <ppisati> [ 3757.373413] usbcore: registered new interface driver dm9601
[11:52] <ppisati> orated: ^^
[11:53] <ppisati> works here
[11:54] <ppisati> orated: what's the output of your power adapter used with BB?
[11:54] <ppisati> orated: i'm using a 5v 3.8A adapter
[11:55] <orated> 5V 900mA for BB, 5V 2.6A for hub
[11:57] <ppisati> ah
[11:57] <ppisati> orated: i doubt that's enough
[11:57] <orated> current rating, yes
[11:58] <ppisati> but when you attach stuff, it drains power
[11:58] <ppisati> orated: try with a beefier adapter
[12:00] <orated> ppisati: Yes, one moment. brb
[12:27] <bjf> ppisati: bug 951043 needs verification, can you take care of that ?
[12:27] <ubot2`> Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,Confirmed] https://launchpad.net/bugs/951043
[12:28] <ppisati> bjf: ack
[12:48] <orated> ppisati: Is it possible to install xfce/gnome and opencv offline on SD card and run them on BB?
[12:49] <ppisati> orated: an a BB board? no way, it'll swap like hell
[12:49] <ogra_> on a BB rev. B !
[12:49] <ogra_> (600MHz/128MB ram)
[12:50] <ogra_> probably lxde or a standalone window manager might work ... 
[12:50] <ogra_> xfce and gnome are surely to big for that
[12:50] <ppisati> bjf: there's no mention of any test to validate that bug, i can confirm the patch is there and kernel boots, but not much more
[12:52] <orated> Afaik, its lxde>xfce>gnome>KDE in incresing order of memory consumption
[12:52] <orated> So, is it possible to install lxde and openCV offline on SD or atleast openCV?
[12:53] <ogra_> yes, install qemu-user-static on your host PC ... 
[12:53] <ogra_> then *manually* mount the SD, copy qemu-arm-static from /usr/bin of the host into /usr/bin of the SD and you can chroot into the SD card
[12:54] <orated> ogra_: Does chroot requires that the host and guest should be of same architecture... arm-arm, x86-x86 ?
[12:54] <ogra_> not with qemu-user-static
[12:54] <orated> Ah-ok
[12:55] <ogra_> but you need to copy the binary from the host to the same place on the SD
=== yofel_ is now known as yofel
[14:11] <tgardner> ogasawara, whats the story on 3.4.0-4.9 ? Is that the version you intend to upload ?
[14:12] <ogasawara> tgardner: it is, just wanted to get a quick powerpc build and will then upload.
[14:12] <tgardner> ogasawara, ok, I'll start the precise backport
[14:12] <ogasawara> tgardner: I just wanted to shove the closing commit in there in case I/you wanted to get a jump on the 3.5-rc1 rebase
[14:13] <ogasawara> tgardner: I have not yet pushed it to master
[14:13] <tgardner> ogasawara, nah, I think we can wait until -rc2
[14:13] <ogasawara> tgardner: ack
[14:14] <tgardner> ogasawara, 'sides, I'm bailing for a week and don't wanna start something I can't finish today.
[14:14] <ogasawara> tgardner: I was also looking at the highbank meta package patch, is there a specific reason we mark the linux-headers-<flavor> packages as "Section: devel" rather than "Section: metapackages"?
[14:15] <ogasawara> tgardner: I notice it's only the headers meta packages which are marked devel, all other meta packages are marked as metapackages
[14:19] <tgardner> ogasawara, missed that. I'll fix it.
[14:22] <tgardner> ogasawara, ok, now I've read your comment for content. I don't think 'Section:' has any real impact in the Ubuntu archive, but I'll ask just to be sure. In the meantime I think its OK as its been that way for multiple releases.
[14:23] <ogasawara> tgardner: indeed, I don't think it should hurt anything and should be ok to fix up later if we want to
[14:23] <tgardner> ogasawara, its a simple change, so I might as well get it in before A1. gimme a minute.
[14:26] <tgardner> ogasawara, hmm, I wonder wtf 'Section: restricted/metapackages' means for powerpc*  ?
[14:27] <ogasawara> tgardner: hrm, no idea there
[14:27] <tgardner> why not just 'Section: metapackages' ?
[14:27] <ogasawara> tgardner: that sounds fine to me
[14:28] <ogasawara> tgardner: I've been trying to find a defined list for Section: but have been unsuccessful in my searching
[14:29] <tgardner> ogasawara, ok, I pushed both changes, so I guess we'll just see what breaks.
[14:29] <ogasawara> tgardner: ack
[14:40] <infinity> Anyone know why the ti-omap4-tools package was dropped from linux-ti-omap4?
[14:40] <infinity> tgardner / apw: Also, apparently it's our PlusOneMaint month.  Had you guys sorted out how you plan to split your time?
[14:42] <tgardner> infinity, all of the omap tools should come from the main kernel.
[14:43] <tgardner> infinity, apw will get started on +1 maint after the UK holiday. perhaps wednesday ?
[14:43] <infinity> tgardner: I thought tools had to precisely match ABI or some such, hence the extra packages from out-of-tree builds?
[14:43] <infinity> tgardner: (This was always the case in previous releases, but I'm happy to be told that was a mistake)
[14:43] <tgardner> infinity, perf is the only tool that is ABI sensitive. lemme review... its been awhile.
[14:44] <infinity> tgardner: Right, and perf is part of -tools. :P
[14:44]  * ogasawara back in 20
[14:44] <tgardner>  I'm not sure we're even building perf 'cause it was causing FTBSs, but that was a bit ago during early -rc's
[14:44]  * infinity checks the linux-ti-omap4 changelog.
[14:47] <infinity> I see no mention in the changelog of dropping the tools build, it just disappeared with no word.
[14:50] <tgardner> infinity, looks like I turned it off during the early dev cycle because of FTBS. 'UBUNTU: [Config] armhf: do_tools=false'
[14:52] <infinity> tgardner: Oh, was that in the changelog and I'm just blind?  Or just in the git logs?
[14:53] <tgardner> infinity, just the git logs
[14:53] <infinity> Anyhow.  Not world-ending for now, just makes the tools metapackage uninstallable, but would be nice to restore it if and when it can be made to work.
[14:53] <tgardner> infinity, working on it...
[14:53] <infinity> Or maybe it'll all become moot if omap4 upstreaming keeps going well, and we can build 3.5 from mainline.
[14:53]  * infinity crosses his fingers.
[14:54] <tgardner> infinity, ain't gonna happen. there is still a pile of BSP patches for ti-omap4
[14:54] <infinity> At which point, to keep ppisati from getting bored, we'll have to get him to do an mx6 or omap5 or something. ;)
[14:54] <tgardner> 5 is coming
[14:55] <infinity> tgardner: Shame.  I was led to believe it was getting close.  Though, maybe we're still carrying some "won't ever go upstream, don't even try" bits.
[14:55] <ppisati> it's already here, i didn't turn it on yet
[14:56] <orated> Sorry, got disconnected before. Thanks ppisati and ogra_ for help
[14:57] <infinity> ppisati: Does that mean you have a Panda5, or have you just been doing omap5 blind and hoping it will boot? ;)
[15:08] <ppisati> infinity: it means the BSP supports both omap4 and omap5
[15:08] <ppisati> infinity: but i din't enable the omap5 side yet
[15:09] <infinity> ppisati: Ahh.
[15:10] <ogra_> thats what they tell you :P
[15:11] <dreks> I'm trying to set up L2TP over IPSec and I've got the IPSec conn established. When I try to start the L2TP connection with xl2tpd, the kernel log starts filling and PC becomes unusable. I have tested the exact same setup on in virtualizatin and its flawless. I believe it has something to do with my ethernet hardware/kernel combination.
[15:12] <dreks> I've posted a portion of my kern.log here, http://paste.ubuntu.com/1023244/
[15:12] <dreks> I've tried grabbing the Realtek driver for the integrated adapter straight from their site and using that. It produced the same result.
[15:12] <ogra_> dreks, your message might become readable if you change your colors ...
[15:13] <dreks> Sorry.
[15:14] <dreks> That better?
[15:14] <ogra_> yep 
[15:14] <dreks> I'm trying to set up L2TP over IPSec and I've got the IPSec conn established. When I try to start the L2TP connection with xl2tpd, the kernel log starts filling and PC becomes unusable. I have tested the exact same setup on in virtualizatin and its flawless. I believe it has something to do with my ethernet hardware/kernel combination.
[15:14] <dreks> I've posted a portion of my kern.log here, http://paste.ubuntu.com/1023244/
[15:14] <dreks> I've tried grabbing the Realtek driver for the integrated adapter straight from their site and using that. It produced the same result.
[15:16] <tgardner> dreks, try the quantal kernel from https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[15:17] <dreks> ok, i can try that. Thanks. Do you see anything in the logs that might indicate kernel over driver problem?
[15:18] <tgardner> dreks, the r8169 driver has had lots of problems in the past, so I suspect you might be right.
[15:20] <dreks> Is there anywhere else I can look for driver related bugs? I'd like to find out whats to blame, kernel or driver
[15:21] <dreks> If I need to replace a ethernet card because the issue has not been resolved with the driver, I will do so, but I want to find evidence it's not the kernel
[15:21] <tgardner> dreks, you could try asking romieu@fr.zoreil.com (the maintainer). be sure to Cc: netdev@vger.kernel.org
[15:22] <dreks> thanks
=== tgardner is now known as tgardner-afk
=== tgardner-afk is now known as tgardner
[15:52]  * ppisati -> gym
[17:45] <tgardner> ogasawara, so, you're happy with Ubuntu-3.4.0-4.9 ? I'll get the LTS backport started.
[17:45] <ogasawara> tgardner: I am, just pushed to master.  Am prepping the upload right now.
[17:46] <tgardner> ogasawara, yep, saw that when I jst pulled.
[17:46] <tgardner> just*
=== tgardner is now known as tgardner-afk
[18:05] <infinity> tgardner: So, linux-ti-omap4-tools-3.4.0-201 is now the only thing standing between me and beer on the archive health reports. ;)
[18:05] <infinity> ppisati: ^
[18:05] <infinity> ppisati: Do you know if the tools can be re-enabled (or, if they need fixing, can we?)
[18:06] <tgardner-afk> infinity, I've got a test build going. if successful I'll upload later this afternoon
[18:06] <infinity> tgardner-afk: Ahh, fancy.  Thanks.
[18:06]  * tgardner-afk is now really afk...
[18:51] <infinity> ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005699 is preventing us from upgrading some of our buildds to precise.  Is there a formal escalation process for these sorts of things?
[18:51] <ubot2`> Launchpad bug 1005699 in linux "tg3: reports "eth0: DMA Status error. Resetting chip.", fails to work" [High,Confirmed]
[18:52] <ogasawara> infinity: usually assigning it to the canonical-kernel-team in lp gets it on our radar, or pinging us directly like you've just done
[18:53] <infinity> ogasawara: Looks like it's fixed upstream, so should just be some tedious bisection back and forth.
[18:53] <ogasawara> infinity: ack, will get a resource on it and get it sorted
[18:53] <infinity> (Or perhaps not even that, if the changes to the driver are limited and obvious, I guess)
[18:53] <infinity> ogasawara: <3
[19:18] <orated> ogra_: Still there?
[20:59] <Kano> hi
[21:00] <Kano> i see your quantal builds need libc 2.14
[21:01] <Kano> is it possible to lower that to libc 2.13 as debian only uses 2.13
[21:11] <jjohansen> ogasawara: so I looked into CONFIG_NF_CONNTRACK_PROCFS its obsolete, and should not be set (so no change) do you want an email to the list before I mark the wi done
[21:12] <ogasawara> jjohansen: if you could just send a quick email that'd be great.  it'd be nice for historical tracking purposes.
[23:36] <infinity> tgardner-afk: Tools build for ti-omap4 seems to be missing a build-dep on flex.
[23:36] <infinity> (at least)
[23:37] <infinity> tgardner-afk: There's also the warnings about missing newt/gtk/python support due to not having those dev packages installed, but I'm guessing you don't turn those on for the master branch either?