[00:33] <Awsoonn> bug 901770 I attached a pic of a KP stack trace, there is a function in the trace called "string.isra.3" I've found the 'string' fuction it's referencing but what does the  .isra.3 mean?
[00:33] <ubot2> Launchpad bug 901770 in linux "Kernel Bug in bluetoothd?" [Medium,Confirmed] https://launchpad.net/bugs/901770
[09:27] <apw> hggdh, yes it should, there is cirtianly postinst for it in later versions
[09:27] <apw> hggdh, it was a known issue with the initial versions that it did not
[09:43] <apw> ppisati, next time we do a ti-omap4 rebase we should include the changelog fragment from->to from the original tree.  there is a helper in the tree for this called insert-ubuntu-changes, which adds changlog information to your changelog if you have a startnewrelease already
[09:44] <apw> ppisati, ./debian/scripts/misc/insert-ubuntu-changes debian.ti-omap4 Ubuntu-3.2.0-3.8 Ubuntu-3.2.0-3.9
[09:44] <apw> ppisati, in theory that puts the right stuff in, its broken it seems, will fix
[09:49] <apw> ppisati, ahh me being dense.  So it takes a changelog of course ...
[09:49] <apw> ./debian/scripts/misc/insert-ubuntu-changes debian.ti-omap4/changelog Ubuntu-3.2.0-3.7 Ubuntu-3.2.0-3.8
[09:49] <apw> +  [ Ubuntu: 3.2.0-3.8 ]
[09:49] <apw> +
[09:49] <apw> +  * armhf -- add d-i configuration
[09:49] <apw> +  * armhf -- disable ABI checks for armhf
[09:49] <apw> +  * armhf -- add arch to getabis config
[09:50] <apw> ppisati, so it does something like that, which you then can commit as 'UBUNTU: rebase to Ubuntu-3.2.0-3.8' or whatever
[09:50] <apw> that way the derivative branch contains hints as to the real changes coming over
[09:50] <apw> and also any bug numbers that were fixed in the master branch too
[09:51] <apw> ppisati, make sense ?
[09:55] <ppisati> uhm, nice, didn't know about it
[09:56] <apw> ppisati, yeah my fault should have mentioned it before, we use it on like -ec2
[09:58] <apw> ppisati, and it copes with more than one version, so if you rebase forward 4 versions just put the old and new base versions and it will insert multiple sections
[09:58] <apw> smb, any idea if the use of ubuntu-insert-revisions is documented anywhere?
[09:59] <ppisati> friday off, he is not here i think
[09:59] <apw> ahh good point
[12:21] <vanhoof> oooh
[12:21] <vanhoof> new kernel fun :)
[12:21]  * vanhoof installs 3.2.0-1402.2
[12:26] <vanhoof> ppisati: apw: that's published now right?
[12:37] <ppisati> yep
[12:42] <vanhoof> ppisati: \o/
[12:42] <vanhoof> vanhoof@panda:~$ cat /proc/version_signature 
[12:42] <vanhoof> Ubuntu 3.2.0-1402.2-omap4 3.2.0-rc4
[12:42] <vanhoof> heyoooo
[12:42] <vanhoof> it booted :D
[12:44] <ogra_> why wouldnt it :)
[12:44] <ogra_> we are professionals, you know *g*
[12:44] <vanhoof> i have serious paranoia problems with this board :)
[12:44] <ogra_> now try armhf :)
[12:44] <vanhoof> it's been through a lot :)
[12:46] <vanhoof> ogra_: it was broken for 6 months :)
[12:46] <ogra_> huh ? what was the bug ?
[12:46] <vanhoof> ogra_: haha
[12:46] <vanhoof> ogra_: tornado
[12:46] <vanhoof> http://ubuntuone.com/3I34mVXLaXZDUEGUeN9l1P
[12:46] <ogra_> oh indeed :)
[12:47] <vanhoof> hdmi is hosed on it (no signal)
[12:47] <vanhoof> but serial works
[12:47] <vanhoof> and jk- recommended putting it in the dish washer
[12:47] <ogra_> ah, then you are one of our server image users :)
[12:47] <vanhoof> and what'dya know
[12:47] <vanhoof> it works again :)
[12:47] <vanhoof> yup
[12:47] <ogra_> haha
[12:47] <vanhoof> figured i'd make some use of it
[12:47] <ogra_> awesome 
[13:02] <apw> vanhoof, the hdmi works now?  or the board boots now
[13:02] <vanhoof> apw: board boots
[13:02] <vanhoof> still no hdmi
[13:03] <apw> heh that is something i guess
[13:04] <vanhoof> yeah :)
[13:04] <vanhoof> better than a cool looking paper weight 
[13:19] <alkisg> Hi, does this screenshot look like it can be caused by a corrupted ext4 filesystem? http://alkisg.mysch.gr/steki/index.php?action=dlattach;topic=4145.0;attach=2676;image
[13:19] <alkisg> It does that when the teacher runs "mksquashfs"
[13:20] <vanhoof> ogra_: n00b in this space 
[13:20] <vanhoof> ogra_: but a quick q
[13:21] <vanhoof> ogra_: would like to add a bit more disk space, any recommendations on what's the best fit, short of a usb device?
[13:21] <vanhoof> (if you have a sec)
[13:22] <ogra_> well, a bigger SD then ... 
[13:22] <ogra_> you only have these two options
[13:22] <vanhoof> ogra_: best route then?
[13:22]  * vanhoof has a 4gb sdhc card presently
[13:22] <ogra_> Sd is indeed slower than USB
[13:23] <ogra_> i would keep the 4G and have a build chroot on a USB disk (for speed)
[13:23] <ogra_> beyond that 4G should suffice for smaller stuff indeed, especially if you use the server image
[13:24] <vanhoof> yeah server image, but have abused a bit of the free space with some local builds :)
[13:24] <ogra_> (you can delete the package pool on the server image (see sources.list.d) that will give you a lot extra space)
[13:25] <ogra_> we shipe quite a big archive inside the image (so you can install server packages without needing network)
[13:25] <ogra_> *ship
[13:27] <vanhoof> oh yeah
[13:27] <vanhoof> root@panda:/var/lib/preinstalled-pool# du -shc /var/lib/preinstalled-pool/
[13:27] <vanhoof> 441M    /var/lib/preinstalled-pool/
[13:27] <vanhoof> 441M    total
[13:27] <vanhoof> ogra++ thanks for the tip
[13:28] <ogra_> :)
[15:27]  * ogasawara back in 20
[16:32] <Wipster> I have found that if I disable dma with the boot option libata.dma=0 I cant access my harddrive and get READ MULTIPLE errors in dmesg, this relates to bug #897777
[16:32] <ubot2> Launchpad bug 897777 in linux "DMA bug with ICH7-M" [High,Confirmed] https://launchpad.net/bugs/897777
[16:33] <Wipster> Unless thats not how to disable dma, looks like the problem is somewhere else?
[17:17] <brendand> jsalisbury - hi
[17:23] <jsalisbury> brendand, hello
[17:37] <mfisch> is there a way to tell if a what parts of kernel firmware are being used at runtime?  something like lsmod for kernel-firmware...?
[17:41] <tgardner> mfisch, there is generally something in dmesg, though it may be driver specific. You can also look in the udev logs
[17:41] <mfisch> tgardner: yeah I knew about the logs.  sounds like that's the only option
[17:42] <tgardner> mfisch, what device ?
[17:42] <mfisch> tgardner: this is a general purpose question, no specific device problems
[17:47]  * ppisati -> eod
[18:48] <sbeattie> bjf: you should have new mail.
[18:49] <bjf> sbeattie: thanks, i signed yours, you won't get email :-) (not using caff yet)
[18:49] <sbeattie> bjf: no worries, thanks.
[19:08] <arges> tgardner, are there flags I can pass to the kernel to provide more verbose wifi/iwlagn messages? 
[19:09] <tgardner> arges, dunno, I haven't been at that level in awhile.
[19:09] <tgardner> have you created the bug report yet ?
[19:09] <arges> tgardner, trying to make sure it isn't user error first
[19:10] <wamty> has 'CONFIG_SECURITY_CAPABILITIES' been removed from recent (3.0.x) kernels?
[19:10] <tgardner> wamty, its not in 3.0.x
[19:11] <wamty> hmmmm
[19:11]  * tgardner -> lunch
[19:12] <wamty> BenC
[19:12] <wamty> has 'CONFIG_SECURITY_CAPABILITIES' been removed from recent (3.0.x) kernels?
[19:17] <infinity> wamty: Someone else already answered.
[19:17] <kees> wamty: yup
[19:18] <wamty> but why removed?
[19:18] <wamty> caps are the default module i think
[19:18] <kees> wamty: correct. it's no longer optional. :)
[19:18] <kees> i.e. no config, because it's always there.
[19:23] <arges> tgardner, wow so not only does it disconnect me in n-mode wifi in 3.0.0-12 , but the router goes into a bad state that requires a reset (even wired connection to it doesn't work). For some reason 3.0.0-14, 3.2 seem to work for me in n-mode. now i want to make sure this isn't a router issue, I'm going to check for firmware upgrades.
[19:25] <wamty> i can log -p security/Kconfig to get the IDs of interesting pieces
[19:25] <wamty> i guess
[19:45] <tgardner> arges, thats a good trick borking your AP
[19:46] <arges> tgardner, yea there is a firmware upgrade so i'm trying that first
[19:58]  * ogasawara lunch
[20:30] <arges> tgardner, https://bugzilla.redhat.com/show_bug.cgi?id=708747 this could be related to my issue
[20:30] <ubot2> bugzilla.redhat.com bug 708747 in kernel "Extremely slow network with Intel "Ultimate N WiFi Link 5300" (iwlagn) after upgrade from Fedora 14" [High,Closed: errata]
[20:30] <arges> trying to figure out why it was marked errata
[20:33] <tgardner> arges, its possibly related
[20:37] <tgardner> arges, you gonna try https://bugzilla.redhat.com/attachment.cgi?id=519535&action=diff ?
[20:37] <wamty> Reversed (or previously applied) patch detected!  Assume -R? [n]
[20:38] <arges> tgardner, i can
[20:38] <wamty> what do i do?
[20:47]  * herton -> eow
[21:35] <arges> tgardner, ok, been looking at this further. I only see this weird n-wireless router behavior in 3.0.0-12 and not  in 3.0.0-13.15 or 3.2.0 or even 2.6.38/natty. 
[21:42] <tgardner> arges, glp Ubuntu-3.0.0-12.20..HEAD -- drivers/net/wireless/iwlwifi/
[21:42] <tgardner> 0a443e57caa1e18b16136e75ce0dc44b14c4c967 iwlagn: do not use interruptible waits
[21:42] <tgardner> 5b483fbe23b7264976c5db37e74cca3fd33ed3b0 iwlagn: fix dangling scan request
[21:42] <tgardner> 59f53ce22e0166ac046b63f73193f233b1d3a1b0 iwlagn: workaround bug crashing some APs
[21:42] <tgardner> 2d8483fafb989e81b1084476110499a8611b0ca6 iwlagn: fix command queue timeout
[21:43] <arges> tgardner, ok thanks. looks like im not reproducing the original issue I was trying to reproduce then!
[21:57]  * tgardner -> EOW