[00:00] <bjf> jsalisbury, so basically we just have to be careful asking for "mainline" kernel testing with samsung laptops and efi mode
[00:01] <jsalisbury> bjf, ack.  I'll be sure to note the model for future requests.  I requested v3.8-rc6 for that particular bug, but I'll hold off on asking for any mainline testing on Samsungs until the patch lands in all the releases.
[00:01] <jsalisbury> bjf, better be safe than sorry
[00:02] <jsalisbury> bjf, thanks for the heads up
[00:02] <bjf> jsalisbury, np, i saw that you gave the correct kernel version. i just worry people might miss that in a rush to test.
[00:02] <jsalisbury> bjf, agreed
[00:37] <bjf> ogasawara, i reviewed the release notes and what you have so far looks good to me
[07:27] <ppisati> moin
[08:10] <smb> ciao
[09:39]  * apw whines
[09:42] <smb> Same procedure as every day...
[13:39] <herton> ppisati, will be ti-omap4 branch removed from raring (along with the packages in the archive)?
[13:39] <ppisati> herton: if everything goes as planned, yes
[13:39] <ppisati> herton: but we can't do that now
[13:40]  * ppisati is exactly tracking down a BUG() in -omap that affects omap4 boards
[13:40] <ppisati> then ill have to fix cpufreq and drm
[13:40] <herton> ppisati, ack. I disabled yesterday ti-omap4 bug tracking opening from the bot for raring.
[13:40] <ppisati> and after those, if everything is ok, we will flip the switch
[13:40] <ppisati> herton: ack
[13:51] <ppisati> brb
[14:00]  * henrix -> late lunch
[14:31] <didrocks> apw: hey, how are you?
[14:31] <apw> didrocks, ok thanks, you ?
[14:32] <didrocks> apw: I'm good, thanks! :)
[14:32] <didrocks> apw: I think you know about that issue, as the hardware is pretty common, but with a wifi card Intel Centrino Advanced-N 6205 (2x2 AGN), the connexion has always been pretty poor
[14:32] <didrocks> for the past 3 weeks though, it's even worse, and I have regular connexion drop
[14:32] <didrocks> tjaalton is experiencing the same
[14:32] <didrocks> (raring)
[14:33] <didrocks> not really sure from where to start, I found bug #937118 which can be similar
[14:33] <ubot2> Launchpad bug 937118 in linux (Ubuntu) "8086:0084 Wireless stops passing packets" [High,Expired] https://launchpad.net/bugs/937118
[14:33] <tjaalton> yeah I've had it with t420s since I got it
[14:33] <didrocks> popey has the same card IIRC
[14:35] <apw> so has it ever worked, the norm is to try and find somewhere it did
[14:35] <apw> and try then to find when it went south
[14:35] <didrocks> apw: it worked, but the reception always have been borderline, not sure for tjaalton?
[14:35] <rtg_> also, think about what might have changed in your environment. new access point ?
[14:36] <didrocks> rtg_: if you look at this card with "ubuntu", you will find a lot of similar cases, so I doubt it's something due to the environment
[14:36] <tjaalton> it works, just that for instance ssh connections tend to get stuck for a while etc
[14:37] <rtg_> didrocks, I'm well aware of the issues. we've had this problem for quite awhile. you could try disabling 802.11n
[14:37] <tjaalton> I've had the same issue with both of my access points (old buffalo, new asus rt-n66u)
[14:38] <didrocks> rtg_: any guide how to do this? I guess I don't need the n norm yeah
[14:39] <sforshee> didrocks, it's controlled by the 11n_disable flag to the iwlwifi module
[14:40] <rtg_> ddiyeah, what sforshee said
[14:40] <rtg_> didrocks, ^
[14:40] <Sarvatt> didrocks: 3.7.0-7 still works properly if you need something working, intel wifi is just busted in 3.8
[14:41] <didrocks> I just set that in /etc/modprobe.d/iwlwifi.conf and at next module reload, it should be disabled, right?
[14:41] <sforshee> didrocks, yes
[14:42] <didrocks> Sarvatt: oh, interesting to know, at least, there is a starting point to know when it did work :)
[14:42] <Sarvatt> https://patchwork.kernel.org/patch/2007911/
[14:42] <didrocks> (and a workaround)
[14:42] <Sarvatt> most likely that
[14:43] <sforshee> a lot of folks have been having problems for a while now
[14:43] <didrocks> Sarvatt: yeah, probably, thanks for the link!
[14:43] <tjaalton> "driver channel switch failed, disconnecting", that's what my dmesg seems to have
[14:44] <rtg_> sforshee, oh, isn't that background scanning ? I've always thought that was a lousy feature.
[14:44] <xnox>  dlm-pcmk was dropped in precise, yet when I try to start cman, it tries to $ modprobe dlm which fails with FATAL: Module dlm not found.
[14:44] <xnox> where do I get dlm module from?
[14:45] <sforshee> rtg_, it might be. Intel wireless does background scanning in hw though
[14:47] <sforshee> didrocks, tjaalton, Sarvatt: you're all getting the "channel switch failed" message? I'll follow up on the upstream thread to let them know there are more people seeing this.
[14:47] <sforshee> I should test with some of my kit as well
[14:47] <xnox> aha, why is dlm module not included in the linux-image-virtual flavour?
[14:47] <sforshee> I think this must be a new problem separate from the other iwlwifi problems people have been seeing for a while now
[14:47] <Sarvatt> checking my logs, I don't remember seeing any error, just unusably slow wifi
[14:48] <didrocks> sforshee: no, I don't get that message in dmesg, however, it seems to happen indeed when it's scanning
[14:48] <Sarvatt> its been a problem since 3.8-rc1 here
[14:49] <tjaalton> sforshee: just noticed it, looks like it's not a common error message here.. just one match zgrepping through syslog.*
[14:49] <sforshee> the commit from the mailing list thread is from 3.8-rc4
[14:50] <sforshee> so probably not the same problem
[14:51] <tjaalton> what seems more common is "deauthenticating from ... by local choice (reason=3)"
[14:51] <sforshee> tjaalton, is that new? Or have you been getting it for a while?
[14:52] <tjaalton> sforshee: goes back to Jan 24th, that's the oldest remaining logfile I have around
[14:52] <Sarvatt> sarvatt@tangerine:~/linux-2.6$ git describe f590dcec944552f9a4a61155810f3abd17d6465d
[14:52] <Sarvatt> v3.8-rc1-2-gf590dce
[14:53] <Sarvatt> i'll try reverting it just in case
[14:53] <sforshee> Sarvatt, do 'git describe --contains'
[14:53] <sforshee> that will tell you the first tag containing the commit, which came out 3.8-rc4 for me
[14:54] <Sarvatt> oops :)
[14:54] <Sarvatt> bisect it is
[14:54] <sforshee> for any problems which started in 3.8, bisecting is a good idea
[14:55] <tjaalton> sforshee: oh, kern.log has older entries
[14:56] <sforshee> we've known of problems with iwlwifi for a while, the problem is that testers haven't been reliable and bugs have gotten flooded with a variety of different problems
[14:57] <tjaalton> ok, so we can create private bugs to track individual bugs without attracting too many me-too'ers? :)
[14:58] <sforshee> yes, you can create a private bug and assign to me and we can start trying to work through things
[14:58] <tjaalton> cool
[15:04]  * sforshee is seeing poor iwlwifi performance in 3.8 too
[15:34]  * ogasawara back in 20
[15:45] <jsalisbury> ##
[15:45] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC
[15:45] <jsalisbury> ##
[17:06] <rtg_> apw, was looking at one of your work items re: switch ureadahead to new in kernel interfaces.  isn't that already done ? or did you just backport the old interface to the kernel ?
[17:07] <apw> rtg_, i fixed the old ubuntu patch indeed
[17:08] <apw> rtg_, and with the backports this is probabally a good thing
[17:08] <rtg_> apw, indeed
[17:08] <rtg_> guess I should pump up a new raring backport
[17:13] <davmor2> hey guys,  I have a lenovo ideapad y580 and after a lot of research via google it seems the only way to have the bluetooth operational is to dual boot it with windows and then enable it in windows and then it just works in Ubuntu/Linux   I ws wondering if you guys knew anything that might have the same effect, without the need for windows
[17:14] <rtg_> davmor2, that sounds like a bluetooth firmware issue. 
[17:15] <davmor2> rtg_: quite possible
[17:15] <rtg_> davmor2, I think there are issues with some BT firmware being redistributable. is there anything in your dmesg that complains about not finding it ?
[17:19] <davmor2> rtg_: paste.ubuntu.com/1613446
[17:21] <rtg_> davmor2, hmm, kind of looks like it started up correctly. have you 'dmesg|grep -i firmware' ?
[17:22] <davmor2> rtg_: paste.ubuntu.com/1613456
[17:25] <rtg_> davmor2, I guess I'd suggest you start an LP bug, then email the bluetooth developers list.
[17:25] <davmor2> rtg_: thanks will do
[17:53] <rtg_> henrix, herton: need to reboot gomeisa for kernel update
[17:53] <henrix> rtg_: ack
[17:53] <herton> rtg_, ack
[17:56] <rtg_> bjf, quantal has 372 commits since the last release
[17:56] <bjf> rtg_, yup
[18:03] <ohsix> damn i didn't even know about ec_sys and nobody mentioned it while i was debugging my backlight freezing problems, i can diff the EC memory and see what happened
[18:12] <sforshee> didrocks, tjaalton, Sarvatt: so it looks like the iwlwifi problems I'm seeing in 3.8 are caused by the commit referenced at https://patchwork.kernel.org/patch/2007911/
[18:12] <sforshee> I've got a test build with the patch reverted, let me post it somewhere so you all can test it as well
[18:12] <Sarvatt> sforshee: it's highly possible i'm mistaking -rc1 with 3.8.0-1 which was rc4
[18:12] <Sarvatt> which would make sense :)
[18:13] <sforshee> Sarvatt, I tested the 3.8-rc1 mainline ppa build and it was fine for me
[18:13] <sforshee> my problem appeared in -rc4
[18:13] <sforshee> I've already responded on the mailing list thread, so I'd expect them to revert the patch for -rc7
[18:14] <Sarvatt> revert is already queued too
[18:14] <sforshee> oh it is?
[18:14] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git
[18:16] <sforshee> Sarvatt, okay it's already in wireless-testing but not yet in wireless-next
[18:16] <bjf> rtg_, number of commits applied since release: lucid (3308) oneirc (3035) precise (2341) quantal (835)
[18:17] <sforshee> ah no, it wouldn't be in wireless-next
[18:20] <sforshee> rtg_, is gomeisa still rebooting?
[18:21] <Sarvatt> tjaalton: http://kernel.ubuntu.com/~sarvatt/iwlwifi/ kernel with that revert if you want to try it too
[18:21] <rtg_> sforshee, otp
[18:21] <sforshee> Sarvatt, thank. My build is on gomeisa and I can't connect atm.
[18:21] <tjaalton> Sarvatt, sforshee: ok thanks, I'll give Sarvatt's build a go
[18:22] <Sarvatt> i built that first thing but hadn't tried it yet, was still bisecting. go figure :)
[18:22] <Sarvatt> takes about 20-30 minutes to reproduce here
[18:24] <sforshee> well, since you guys have a build to test now I'm going to grab some lunch
[18:30] <jsalisbury> rtg_, do you happen to know if gomeisa is down?
[18:32] <rtg_> jsalisbury, otp, I'll get to it in a bit
[18:32] <jsalisbury> rtg_, ok, thanks
[18:44] <Sarvatt> sforshee: this is working great for me as well, thanks!
[18:49] <tjaalton> I get a sustained 11MB/s copying large files to devnull on another machine hooked on gigabit ethernet
[18:53] <rtg_> jsalisbury, sforshee: working on getting gomeisa power cycled
[18:53] <jsalisbury> rtg_, cool, thanks.  I just moved over to tangerine for now ;-)
[18:55] <rtg_> gomeisa should be cycling. I'll be back after a quick lunch.
[19:14] <dhanasekaran> Hi guys Adaptive RX it's not properly set using ethtool
[20:46] <apw> dhanasekaran, define 'not set properly', and on what device
[20:46] <dhanasekaran> apw: driver: igb  version: 3.2.10-k
[20:47] <apw> and how are telling it doesn't work
[20:48] <dhanasekaran> apw: I want enable Adaptive Rx ethtool -C eth0 adaptive-rx on ; ethtool -c eth0 | grep 'Adaptive RX'
[20:48] <dhanasekaran> I tried Adaptive RX not enable after set
[20:49] <dhanasekaran> I am using 3.2.0-37-generic
[20:54] <dhanasekaran> apw: any help
[20:55]  * ogasawara lunch
[21:16] <apw> dhanasekaran, are you sure that device supports it?  i see that if you set options in that set and they are not supported they are silently ignored
[21:19] <apw> dhanasekaran, it seems to understand the rx_coalesce_usecs and tx_coalesce_usecs
[21:19] <apw> but i don't see anything about the adaptive stuff
[21:21]  * rtg_ -> EOD
[23:00] <BarkingFish> Good evening :)  jsalisbury - is there any chance I could grab you for a quick word please concerning the bug you're helping me to track down please? 1113048, concerning the ar5523 driver?
[23:02] <BarkingFish> I've got the 3 rc kernel candidates you asked me to install, installed - now, ndiswrapper is building in rc2 which is where I am now, so at least I can get on the net.  From what I can find though, the ar5523 module doesn't appear in any of the 3 kernels. 
[23:03] <BarkingFish> I've tried to modprobe it, since it's not picking up on boot - and it just pops up "Fatal: module ar5523 not found"
[23:58] <scientes> is there any repo of just the packaging stuff?
[23:58] <scientes>  /debian
[23:58] <scientes> i want to package an out-of-tree kernel
[23:59] <scientes> that has special bootstrap/install stuff