[00:16] <kees> ogasawara: cool
=== jussi01_ is now known as jussi
[07:40]  * apw yawns quietly to himself
[08:06] <ppisati> morning *
=== smb` is now known as smb
[08:12]  * smb silently sneaks in
[08:18]  * bryceh unobtrusively watches people yawning and sneaking
[10:17] <amitk> apw: is the default now set to mark every bug against "linux" to confirmed?
[10:18] <amitk> bug 838614 was filed by a friend on mine, I didn't know that tomboy is now a kernel driver :)
[10:18] <ubot2`> Launchpad bug 838614 in linux "User experience issue while shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/838614
[10:54] <smb> amitk, Magic (bot) happens when there is apport data I'd say. :)
=== Quintasan_ is now known as Quintasan
[11:04] <amitk> smb: hmm, with brad's name :)
[11:04] <smb> amitk, You know these people, working like machines... :-P
[11:05] <amitk> heh
[12:38] <htorque> hi everyone! don't know if that's the right place to ask, but my new ssd is not used as sata-iii drive and i'm stuck with sata-ii speeds.
[12:38] <htorque> here's a snippet from dmesg: http://paste.ubuntu.com/679685/ (crucial m4 connected to ata1 on an intel z68 based board)
[12:38] <htorque> (using up-to-date oneiric)
[13:31] <smoser> bjf is there a a way i can appease your bot at bug 838199 ?
[13:31] <ubot2`> Launchpad bug 838199 in linux "initramfs blkid /dev/xvda1 did not return, failed boot" [Undecided,Confirmed] https://launchpad.net/bugs/838199
[13:31] <ogasawara> smoser: I just posted a comment there
[13:32] <bjf> smoser, just change the status to "confirmed" and it will leave the bug alone
[13:33] <bjf> smoser, you just tease it when you put it back to "new", note this is actually explained in the comment that is added
[13:43] <_-maks> is there a linux version known that you'll pick for 11.04?
[13:43] <_-maks> debian is freezing in june so we might be able to sync
[13:44] <_-maks> 3.4 looks optimistic but maybe feasible?
[13:44] <_-maks> 3.2 for christmas, so easter with 3.3
[13:44] <_-maks> so maybe to optimistic
[13:45] <bjf> _-maks, did you mean 12.04 ?
[13:48] <ogasawara> _-maks: as bjf mentioned, I assume you mean 12.04.  I don't think any of us have actually yet looked to see where upstream would be at for our 12.04 release, which happens to also be an LTS (long term support) release.
[13:49] <ogasawara> _-maks: being an LTS release, we'd likely err on the side of being conservative
[13:49] <ogasawara> _-maks: and it would be nice to be in sync with other distros
[13:50] <ogasawara> _-maks: if 3.3 looks to be releasing around easter, I suspect that is what's we'd try to target
[13:51] <tgardner> ogasawara, that might be a bit aggressive for an LTS
[13:52] <bjf> ogasawara, tgardner since gregkh is talking about picking a kernel to support for two years, i assume we'll pick his brain next week
[13:52] <smoser> thank you ogasawara bjf . i will try to learn to read.
[13:53] <ogasawara> tgardner: indeed would be nice to know what the next long term kernel will be
[13:55] <bjf> ogasawara, tgardner in case you hadn't seen this already: https://plus.google.com/111049168280159033135/posts/VyWdYvHnAS2
[13:55] <tgardner> ogasawara, if it was just x86 we had to worry about I'd choose 3.2, but I'm sure Linaro will have some influence.
[13:57] <ogasawara> bjf: yep, read in on LKML and tgardner replied
[13:57] <bjf> ogasawara, if it's not on G+ i don't see it :-)
[13:57] <ogasawara> hehe
[13:58] <ogasawara> _-maks: so I think what we're saying is we have no idea yet :)
[13:59] <ogasawara> _-maks: but I can be sure to interlock with you when we do decide.  we should have a better idea around UDS (early Nov).
[14:03] <bjf> _-maks, if you were going to be at plumbers next week we could discuss it there
[14:17] <herton> smb: are you going to rebase ec2 against lucid respin (bug 837804), or that isn't needed? I'm asking because if it will not be rebased I'll mark verification done for the previous ec2 update so it can go to testing
[14:17] <ubot2`> Launchpad bug 837804 in linux-ec2 "linux-ec2: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/837804
[14:18] <smb> herton, I am right now in the process of doing it as the two newer reverts may have a chance to have impact
[14:19] <herton> ok
[14:20] <herton> ppisati: I was checking you lucid/mvl-dove branch, the tag Ubuntu-2.6.32-218.36 isn't pointing to the top of your tree (I was expecting it pointing to commit 2dcf1e845f2b8986e50510acaf13ca0b24a96497)
[14:22] <ppisati> herton: strange
[14:22] <ppisati> let me see
[14:25] <_-maks> bjf: icj (Ian Campbell) will be at plumbers
[14:25] <_-maks> I won't make it this year.
[14:26] <_-maks> XenSource guy
[14:26] <_-maks> he is from ours too.
[14:29] <ppisati> herton: what about now?
[14:32] <herton> ppisati: looks ok now
[14:53] <htorque> meh, so my sata-iii ports work at sata-iii speed depending on having disks attached to sata-ii ports or not - is this a bios/efi problem or something kernel-ish to report?
[14:58] <Tommeh> htorque: you might need to explain that a bit better.
[14:58] <Tommeh> I don't fully understand what scenario you're referring to -- it could be one that's expected or not.
[15:02] <htorque> ok, sorry. i attached a sata-iii ssd to a sata-iii port on a intel z68 based motherboard but speeds were capped at sata-ii speed (tested using palimpsest). i then removed my also attached sata-ii hdd from its sata-ii port and now i'm getting full speed from the ssd.
[15:07]  * ogasawara back in 20
[16:06]  * herton -> lunch
=== kamalmostafa is now known as kamal
[17:18] <cnd> sforshee, I was trying to respond to your email, but it seemed easier to chat about it
[17:18] <cnd> are you around?
[17:48]  * tgardner --> lunch
[17:52] <cnd> sforshee, I got tired of waiting, so I typed it all out :)
[18:05] <sforshee> cnd, I'm back, just read your email
[18:05] <cnd> k
[18:06] <cnd> I'm happy to chat if you have any thoughts
[18:06] <sforshee> first off, Dmitry said in the elantech patch review that MT coordinates should be scaled up to the same scale as single-touch coordinates
[18:06] <sforshee> as far as the points being different, it could be bigger than you're assuming
[18:06] <sforshee> I'm reporting (min_x, min_y) and (max_x, max_y) pairs
[18:06] <cnd> sforshee, yeah, I saw those comments from dmitry, but I didn't look too closely
[18:07] <sforshee> whereas the fingers could actually be at opposite corners
[18:07] <sforshee> opposite from what we're reporting, that is
[18:07] <cnd> oh, that's fine
[18:07] <cnd> that's what SEMI_MT is all about :)
[18:07] <sforshee> and if there are more than 2 fingers, I have no idea what the single-touch coordinate the device is reporting corresponds to
[18:07] <sforshee> could be something in the middle
[18:08] <cnd> sforshee, the point is that the bounding box should be accurate
[18:08] <cnd> as long as that is accurate, it doesn't matter where the touches are physically
[18:08] <cnd> that's the best we can do
[18:09] <sforshee> and the ABS_[XY] pair doesn't have to correspond to one of the corners of the bounding box, correct?
[18:09] <cnd> nope, it should just be inside the bounding box
[18:10] <cnd> which may be another reason why the mt axes should have less range
[18:10] <sforshee> okay, we should be good there then
[18:10] <cnd> otherwise, if you scale up your ST coords may not live exactly inside the box
[18:10] <cnd> they could be a few units outside
[18:10] <sforshee> hmm, I guess so, but that's still counter to what Dmitry said
[18:11] <cnd> yeah, I'm going to find the patches and bring it up on the thread
[18:11] <sforshee> it was on probably the first version of the patches from elantech, they're on something like v4 now
[18:12] <sforshee> cnd, https://lkml.org/lkml/2011/8/18/69
[18:13] <sforshee> but for their patches it won't matter because the ABS_[XY] is always also one of the MT points
[18:14] <cnd> sforshee, you've read the elantech patches more than I, so I'll ask you some questions
[18:14] <sforshee> ok, shoot
[18:14] <cnd> does the elantech have the same resolution for MT and ST data?
[18:14] <cnd> was dmitry's issue just that it could concievably be different?
[18:14] <cnd> or is it like the alps stuff
[18:15] <sforshee> actually I'll have to look, I just remembered that this is wrt the v2 protocol which I'm not familiar with :)
[18:15] <cnd> sforshee, do you mind if I mention your work with the alps trackpad?
[18:15] <sforshee> no, I've already mentioned I'm looking into it on a bugzilla
[18:16] <cnd> ok
[18:17] <sforshee> cnd, it does look like in elantech v2 protocol the MT points are lower resolution than ST
[18:18] <sforshee> (brb)
[18:19] <cnd> ok
[18:20] <sforshee> cnd, but what I said before holds -- the ST point is the same as one of the MT points
[18:20] <sforshee> it will never fall outside the bounding box
[18:26] <cnd> ok
[18:42] <Exodus> Hello
[18:45] <Exodus> How does one inquery a kernel bug here?
=== nickde is now known as Guest38625
[18:45] <Exodus> There's this bug with AHCI being loaded as a module that makes some hardware freeze for 10-25sec on startup
[18:47] <Exodus> If it's compiled into the kernel it doesn't present this issue
[18:57] <ogasawara> Exodus: might help if you mention the actual bug # and which kernel version?
[19:00] <Exodus> Was actually hoping someone would say anything so I don't rant by myself here
[19:00] <Exodus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/297058
[19:00] <ubot2`> Ubuntu bug 297058 in linux "Consistent repeating [ata1: link is slow to respond, please be patient ]" [Undecided,Won't fix]
[19:00] <Exodus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/595448
[19:00] <ubot2`> Ubuntu bug 595448 in linux "Slow boot caused by SATA controller reset (dup-of: 297058)" [Medium,Confirmed]
[19:00] <Exodus> That second one is a duplicate
[19:01] <Exodus> But further down that second one there are very useful comments
[19:01] <Exodus> And tests
[19:01] <Exodus> Bug persists over various distributions
[19:01] <Exodus> and Ubuntu releases
[19:02] <Exodus> I think, compiling AHCI into the kernel instead of loading it as a module will fix the issue
[19:14] <ogasawara> Exodus: considering the second bug has been marked a duplicate of the first and the first is marked Won't Fix I suspect no one is looking at it
[19:15] <ogasawara> Exodus: it's best if you probably file a new bug and confirm it's still an issue with the latest Oneiric beta release that'll come out today
[19:17] <Exodus> Will do
[19:18] <Exodus> Can't someone just reopen the bug?
[19:18] <Exodus> I could just remove the duplicate from the later bug
[19:18] <Exodus> There is a lot of info on those comments
[19:18] <Exodus> And feedback
[19:18] <Exodus> Would be a waste to create a new bug
[19:18] <Exodus> Is creating a new bug the proper way to go?
[19:21] <ogasawara> Exodus: I'd just reference the older bugs in the newer one, or pick out the relevant bits of info and add to the new bug.  the older bugs seem to have some random comments you have to sift through which is annoying sometimes.
[19:22] <Exodus> True, I'll make a new bug then. Thanks.
[20:09]  * ogasawara lunch
[20:21] <Exodus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/839052
[20:21] <ubot2`> Ubuntu bug 839052 in linux "Kernel delays startup for several seconds due to AHCI loading as module" [Undecided,New]
=== yofel_ is now known as yofel
[22:10]  * jjohansen -> lunch