=== kengyu__ is now known as kengyu === smb` is now known as smb [08:30] * ppisati -> reboot [08:54] Hi everyone. [08:55] I know a bit of linux and i am not an expert. [08:55] I have installed 11.10 ubuntu from CD [08:55] many times during the day, it crashes [08:55] i read yesterday that desktop GUI issues are normally kernel issues. [08:55] can someone help please. [08:55] thank you in advance === himcesjf1 is now known as himcesjf [09:03] anyone there === htorque__ is now known as htorque [09:22] hi [09:28] hey apw! I normally get a kernel panic every 2 days (my disk is really slow and I'm under the impression that I trigger it when I do a lot of ios). This morning, I got 3 of them :( what should I provide to help your team debugging? [09:56] didrocks, do you get a stack trace from the crash, thats the most useful part [09:56] apw: never got a crash in /var/crash/ related to the kernel from what I can see [09:57] didrocks, so whats the symptoms when it 'crashes' [09:58] apw: the disk is spinning a lot due to a lot of io, then screen freezes and I see both caps lock and scroll lock flashing which is what tells there is a kernel panic, isn't it? [09:59] didrocks, yes usually flashing those is its last ditch attempt to tell you ... from their its worth doing the sysrq sync as if syslog got the crash it may not hit the disk until you sync [10:00] apw: ok, will do the sysrq sync at my next (hopefully not too soon though ;)) crash [10:00] apw: will keep you posted [10:00] didrocks, which kernel is this running, assuming precise latest? so do get a bug filed so we can track which versions it definatly occurs in [10:01] didrocks, i don't think i've seen any hard crashers this cycle on any of my kit thankfully, they are very hard to locate [10:01] apw: yeah, I got that for 2/3 weeks already, always updated to latest (and updated to latest again this morning) [10:01] apw: yeah, I really think I trigger it a lot as my HD is near EOL [10:01] so all my laptop is very slow due to this, so easier for me to trigger weird cases [10:02] didrocks, i asume its not old enough to have a serial port [10:02] why oh why did they take those off [10:03] apw: no, I would have played with minicom otherwise ;) [10:04] didrocks, sometimes a netconsole will get the crash, sometimes [10:04] interesting, not used to do that though ;) for most of my stack, it's either on a terminal or a tty if it's the window manager. Quite easier ;) [10:09] didrocks, fingers crossed the sync will get it [10:09] apw: I hope so as well. Will keep you in touch, thanks! [10:10] and let us know the bug number so we can get it to jo [10:10] joe [10:18] * ppisati -> back in a bit [11:08] * ppisati -> lunch [11:14] ditto [11:33] *burp* [11:35] satisfying lunch then ppisati? [11:42] well, good enough, thanks for asking :) [12:02] ppisati, Wanna mint? :) [12:13] smb: the meaning of life? :) [12:13] ppisati, yep [12:13] :) === smb` is now known as smb [12:37] b smb [12:37] b happy [13:08] Anyone have any clue when 12.04 will be happily thrust upon us? [13:10] When it is released...? ;) https://wiki.ubuntu.com/ === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ [14:01] hi, please add http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c9651e70ad0aa499814817cbf3cc1d0b806ed3a1 [14:01] if not already done [14:07] apw: https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReviewBeta2omap4 is it periodically autogenerated or you intervene manually? [14:08] ppisati, totally manual, need it updating ? [14:09] apw: not yet [14:10] Kano, that is already applied and uploaded, iirc we were in the loop in getting that fix identified [14:11] fine [14:11] i bisected it again ;) [14:11] then i saw that there was already a fix [14:42] * ogasawara back in 20 [14:45] apw: when there's a dash it means it's not available there, right? [15:00] ppisati, yes right === yofel_ is now known as yofel [15:19] cking, do you have a regression test for bug #885744 ? It needs Oneiric verification. [15:19] Launchpad bug 885744 in ecryptfs "pathconf() does not reflect reality" [High,In progress] https://launchpad.net/bugs/885744 [15:19] tgardner: I'm gonna rebase q to 3.4-rc1, just wanted to make sure you're not already doing so [15:19] tgardner, yep, I'm in the process of verifying these [15:19] ogasawara, nope, still grinding through my email backlog. thats what I get for taking the weekend off. [15:20] cking, thanks [15:21] cking, which reminds me, I should compare 2.6.32.y against our ecryptfs patches and send the deltas to stable [15:33] apw: otoh, the aspm fix hasn't been applied to oneiric-proposed yet... [15:43] * ppisati kicks another build and disappears for a bit in the mean tim [15:43] e [15:43] jwi, just emailed it for review at kernel-team@lists.ubuntu.com === bladernr_ is now known as bladernr_afk [15:48] tgardner, do we not need a second fix from cking on that one ^ ? [15:48] apw, nah, taht was just an override thingy. it wouldn't hurt, but its also not related [15:49] yep [15:49] * apw looks confused [15:49] * apw will let you duke it out on the mail thread [15:50] apw, you're takling about Oneiric "ASPM: Fix pcie devices with non-pcie children", right ? [15:50] tgardner, indeed [15:50] * apw spits feathers at the launcher, get off my damn screen i am using it [15:51] apw, and I assume to 2nd patch to which refer is "UBUNTU: SAUCE: PCI: Allow pcie_aspm=force to work even when FADT indicates it is unsupported" [15:52] cking, is that the one i mean, i know there was a followup for it, which was related to regressions induced by the first patch [15:58] bah it wants to remove all my 32 bit support again ... not a good time to update [16:07] ppisati, did we resolved the issues that pushed us back for beta2 on arm? === bladernr_afk is now known as bladernr_ [16:36] sforshee, have you noticed suspend/resume issues on your MB Air ? [16:36] tgardner, I filed a bug about some touchpad problems after S3, but that's the only one I've seen recently [16:37] sforshee, yeah, I'm seeing mouse lockage === htorque_ is now known as htorque [16:37] sforshee, I didn't notice it until recently 'cause I'd been using an external mouse [16:37] it just showed up recently [16:38] tgardner, bug 968845 [16:38] Launchpad bug 968845 in xserver-xorg-input-synaptics "bcm5974 touchpad doesn't work after S3" [Undecided,Confirmed] https://launchpad.net/bugs/968845 [16:38] if you suspend from the menu things are okay [16:38] sforshee, do you have time to bisect for it? is it a kernel issue ? [16:38] tgardner, I'm pretty sure it's not a kernel issue [16:38] ah, then not a kernel problem [16:39] tgardner, I subscribed cnd to the bug, hopefully he'll have some input [16:40] sforshee, tgardner: no input :( [16:40] I don't know what might have changed [16:40] but there has been some work done to the bcm5974 and suspend stuff [16:41] there might be upstream patches in 3.3 or 3.4 that fix it too [16:41] cnd, it seems like the touchpad still works fine, just that userland isn't doing anything with it [16:41] i'll check upstream for patches though [16:42] sforshee, are you saying that evtest still works, for example, but no events are coming through X? [16:43] cnd, input events shows reasonable-looking events, and if I restart lightdm it starts working fine on the desktop [16:45] sforshee, try using xinput test-xi2 to see if you get events from X [16:46] cnd, yes, I get events [16:46] sforshee, so you get events, but the cursor doesn't move? [16:46] exactly [16:46] sforshee, what kinds of events are you getting when you use one finger? [16:46] touch or motion? [16:46] oh, sometimes I get right clicks too [16:47] cnd, I see RawTouch* events [16:47] sforshee, ok, we don't care about raw events for now [16:47] that's all I'm seeing [16:48] sforshee, what non-raw events do you see if you put two touches down? [16:50] cnd, none, just RawTouch stuff [16:51] sforshee, and three touches? [16:51] apw: nope, since my panda's video out is still broken, waiting for the new one [16:51] also, please pastebin the output of "xinput list-props bcm5974" [16:51] apw: i think it'll have to wait until after first SRU [16:52] apw: since thursday is KF [16:52] cnd, the same [16:52] hmm [16:53] sforshee, check for any errors in your Xorg.log [16:54] cnd, the only thing I find are some "unable to find touch point 0" messages [16:54] hmm... that could be related [16:55] sforshee, I seem to recall someone saying that on lid closure the trackpad sometimes emits touch events [16:55] ppisati, kernel freeze means we move to SRU mode, limiting updates without appropriate acking, its not impossible to get things in, and easier probabally than after release [16:55] ppisati, where is your replacement coming from? [16:55] I don't know if it's a capacitive effect or merely your fingers are close to it when closing the lid [16:56] I wonder if some evdev events are getting lost at suspend/resume time [16:56] so a touch is stuck in the "open" state [16:56] sforshee, it might be worthwhile to do a suspend/resume while recording events using evtest [16:56] cnd, here's something strange [16:56] we probabally reset the thing having powered it off for suspend [16:56] and then seeing if there are any anomalies [16:56] apw: austria, but "upstream" didn't deliver any boards to them yet, it seems there's a shortage [16:57] I'm noticing that right now my one-finger touches are behaving like two-finger touches; i.e. they are causing scrolling [16:57] sforshee, ahh yes! [16:57] that's exactly what I was thinking might be happening [16:57] ppisati, and we don't have any you can test on anywhere we can either get you access to 'em or send one to you? [16:57] sforshee, a touch is stuck in a state where X thinks it is active [16:57] apw: pgraner told me he was sending me a board this week [16:58] sforshee, how reproducible is it? [16:58] apw: actuallyt i could try another rebase tomorrow, and shell it to someone on #arm [16:58] cnd, it happens 100% of the time if I suspend using the lid [16:58] apw: for testing [16:58] ppisati, well thats something, but we should hastle as the timeing is very poor [16:58] ppisati, yes use them and abuse them [16:58] sforshee, ok, then do the evtest thing during a suspend/resume [16:59] let's see if we catch any bad events [16:59] cnd, ack [16:59] cnd, i wonder if it sees its own lid :) [16:59] apw, could be :) [16:59] apw: just to clarify, the TI stuff is up to date (no more pulling from them) we are slacking behind wrt to master [16:59] ppisati, I sent it to millbank and msm will be sending it down to you [16:59] pgraner: k, thanks [17:01] ppisati, ok its arrived in london and i'll be winging its way tommorrow [17:01] cnd, is it important that there be a suspend/resume, or just a lid close/open? Because the device is being grabbed when I'm on the desktop, so evtest can't get the events. [17:01] apw: cool [17:01] sforshee, switch to a VT [17:01] then run evtest [17:02] oh, but then it doesn't suspend [17:02] I see [17:02] yep :) [17:02] sforshee, so you can use an Xorg.conf rule to tell X not to grab the device [17:02] cnd, we need a bpf for the events ... [17:02] I can do sleep 2; pm-suspend on the VT [17:02] apw, bpf? [17:03] berkely packet filter, its whats uses to pick out ehternet frames, and i tink now usb and bt frames [17:03] and they were using it for something else mad the other day, now what was that [17:03] seccomp maybe it was [17:03] syscall filtering [17:03] yep [17:03] so it must be the right thing for event monitoring :) [17:03] heh [17:04] sforshee, there's a better way to do this [17:04] but the faster/hackish way is: [17:05] add 'Option "GrabEventDevice" "false"' to /usr/share/X11/xorg.conf.d/50-synaptics.conf [17:05] inside the touchpad catchall block [17:05] I don't think you'll see any issues when you have the option set [17:05] I think it's there for a couple of very specific circumstances [17:06] sforshee, once you've added it, you need to log out and back in [17:06] then you should be able to evtest while in X [17:06] stopping people reading your keyboard while you are typing perhaps [17:06] apw, no, that input class section is only for trackpads [17:07] at one point I knew why we grabbed devices by default [17:07] it papers over missing functionality needed in the X synaptics driver [17:07] i am glad to hear your brain has flushed that information [17:07] mine does it all the time [17:07] heh [17:08] cnd, that seems to be working [17:08] cool [17:10] cnd, http://pastebin.ubuntu.com/911740/ [17:13] sforshee, did all this occur just by closing the lid? [17:13] oh joy firefox, chromium, and libreoffice updates ... [17:14] cnd, i did wiggle my finger on the touchpad after resume [17:14] sforshee, oh... [17:14] sforshee, can you get a clean recording without any intentional touchpad interaction? [17:14] I can redo it without the wiggling [17:14] thanks [17:14] cnd, though its reporting a 4 finger touch right? and i assume he only did one [17:15] or he used his forhead [17:15] i always use my forhead, is that unusual? [17:15] heh [17:15] apw, good point [17:15] sforshee, did you only use one finger? [17:15] but you do want a clean 'un [17:15] cnd, yep, one finger [17:16] hmm... then my guess is the driver is screwed up too :) [17:17] sforshee, btw, you can probably reset the state back to a good starting point by reloading the bcm5974 driver [17:17] * tgardner relocates [17:18] cnd, non-wiggling evtest output: http://pastebin.ubuntu.com/911751/ [17:18] sforshee, really? [17:18] there's a ton of stuff going on :) [17:18] but it's masked by bad state too [17:19] Event: time 1333386946.147384, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 7630 [17:19] Event: time 1333386946.147386, type 3 (EV_ABS), code 51 (ABS_MT_WIDTH_MINOR), value 6492 [17:19] cnd, reloading bcm5974 did get pointer motion back, and compiz also crashed :) [17:19] sforshee, can you do the same after reloading the driver? [17:19] waht the resolution of this thing ? [17:19] fun... [17:19] thats a pretty big finger in most coordinate systems [17:19] apw, look at the top of the printout [17:19] it gives the axis max and min for each code [17:19] it has a pretty high resolution :) [17:20] so those are outside the surface area then no ? [17:20] cnd, you want the evtest output again after reloading the driver? [17:20] looks like it [17:20] sforshee, yeah [17:20] as its saying 1280x800, and then saying you have a 7k wide finder [17:20] finger [17:20] Max 2048 [17:20] so that number can't be >2k ... ooops [17:21] apw, or the driver writer had never seen a value higher than that [17:21] the X and Y max and min for the magic trackpad are merely the highest and lowest values I could get [17:21] we don't have specs for apple devices :( [17:21] ahh ok [17:22] apw, but those numbers are *way* beyond the max [17:22] so something seems wrong [17:23] cnd, http://pastebin.ubuntu.com/911758/ [17:23] apw, oh, I think I know what's going on with those numbers [17:23] the width values are supposed to be scaled, as best as possible, to device units [17:24] but often times the width values reported by the devices are in some random other unit [17:24] so a scale factor is devised [17:24] I would have rather seen evdev report the raw values from the device; that was a henrik decision [17:26] sforshee, there's still a lot going on, but this is a good baseline [17:26] so in the first packet there are two new touches [17:26] in the second packet there appear to be three touches [17:27] however, BTN_TOUCH is 0 and BTN_TOOL_TRIPLETAP is left at 0 [17:27] I don't understand what is going on there [17:28] cnd, could they be getting softer, cause the pressure is also 0 [17:28] could this literally be the screen bouncing off the touchpad ? does the machine have a touchscreen too? [17:28] apw, could be, but the touches are still active [17:28] apw, touchscreen would be a different evdev node, but this doesn't have a touchscreen anyways [17:28] apw, no touchscreen [17:29] i was more thinking is the screen made of something that acts like fingers, obviously gloved hands don't work etc [17:29] it seems like the single touch events (BTN_TOUCH, BTN_TOOL_*) are not in sync with the mt events [17:29] which is bad enough [17:29] cnd, i dee in the next packet we have 4 taps [17:29] yeah [17:29] I do think there are magnets involved in the lid switch mechanism, which may be close to the touchpad [17:30] sforshee, does the cursor still move? [17:30] then we move, drop to three touches (correctly), back to four, then lose the touch with them again [17:30] after this particular recording [17:30] because all the touches have ended [17:30] cnd, it does now because I reloaded bcm5974 [17:30] oh [17:30] but it didn't after I killed evtest [17:30] hmmm [17:31] * apw wonders if he has any magnest to wave at his touchpad [17:31] heh [17:31] cking, you have magnets i bet ... do they affect touchpads to you know? [17:31] sforshee, I would send a note to henrik, and cc linux-input, asking about this behavior [17:31] I think others have seen it [17:31] but I can't seem to find any emails [17:31] apw, I can find some... let me see what the kids have [17:32] oh i have a fridge magnet, let me try that [17:32] sforshee, there seem to be two issues: [17:32] this machine has an ssd so i should keep the disk contents :) [17:32] 1. the driver is not in sync between mt and st data [17:32] 2. has anyone looked into this already, is there a fix or a workaround? [17:32] apw, so what do you want me to try then? [17:32] cking, does it affect your touchpad at all [17:33] here goes.. [17:33] doesn't on mine (found a ladybird on the fridge) [17:33] apw, I'm failing to get a reaction from the touchpad using a magnet [17:33] apw, no, but my HDD is now wiped ;-) [17:33] sforshee, try taking the screen of another laptop and hovering it over the trackpad? [17:33] * cking saunters off, was on at 7am.. [17:33] maybe the LCD is doing it :) [17:34] cnd, you have a separate one of those don't you? [17:34] cnd, bet the speaker magnets in the LCD are affecting it [17:34] cking, well except they don't on yours at least [17:34] apw, you mean a magic trackpad? [17:34] I could try that [17:34] yeah that is likely similar device is it not [17:35] i guess the trackpads are metal whereas mine may not be, so it may have more effect there [17:35] apw, ooo! [17:35] cnd, it does vomit for some time either side doesn't it [17:35] oooo ! ? [17:35] I got stuff when waving my MT across the top of my macbook lid [17:35] where the magnets are [17:36] there are serious magnets in there [17:36] http://www.gizmag.com/100-tesla-pulsed-magnet/21946/ [17:36] 100 tesla magnet will do [17:36] another apple special then, their own trackpad is affected by the magnets they use to close the box [17:36] actually, it does it to the screen too [17:36] so it may not be the magnets [17:36] cnd, i suspect thats not normal for other touchpad types [17:37] apw, cnd: I can get events by holding a macbook pro near the macbook air touchpad [17:37] apw, hard to tell [17:37] sforshee, so if you shove two or three sheets of paper in the gap and close/open does it do that [17:37] we might be able to tell if its magnets (longer range) or plastic coating touching (short/zero) range [17:37] apw, yes, when the lid is very close to closing I start getting some events [17:37] sforshee, I wonder if you add a resume hook to the driver to reset the state if it will fix things? [17:38] basically it seems to happen at the point where the lid tries to snap closed [17:38] cnd, should we not worry they could make 'valid' events and do something awful like close or move a window [17:38] hmm... good point [17:38] like needing to disable the touchpad stream as soon as the lid event starts or something? [17:38] yeah [17:39] I don't know exactly how you would do that though... [17:39] sforshee, can we tell when the lid event occurs, ie does the machine suspend if you close it reallly really slowly [17:39] cnd, well OSX must be able to cope, so likely the lid event is in before the interferance starts [17:39] sforshee, as a test maybe you could do something like close the lid in glacial time [17:39] and see if it triggers before the events start [17:39] apw, yeah, probably [17:40] apw, but how could you code that up in a linux driver [17:40] ? [17:40] you'd need to let the two kernel dirvers know about each other [17:40] I don't know if there's some way the bcm5974 driver can listen for lid events [17:40] which is vileness extreme [17:40] yes [17:40] Not trivially [17:40] You could add a notificaiton chain [17:40] mjg59, ahh, should have pinged you earlier :) [17:40] Or you could push it out to userspace [17:40] yeah its bound to be a violation of about 20 layering [17:41] mjg59, if you pushed it out to userspace you might have race conditions [17:41] Have a udev helper fire on the lid event and disable any USB input devices that are flagged as non-removable [17:41] mjg59, how could you be sure the bcm5974 driver will get it in time? [17:41] cnd: It's going to be racy on a multi-threaded system in any case [17:41] I'm not meaning issues between cores [17:41] I mean issues in time [17:41] i think if it even does it of course, you would have to have the MT driver check before emitting any packet [17:42] which would mean looking at something global and shared in the kernel, which stinks [17:42] like, the event reaches userspace, userspace processes it and turns the touchpad off in 100 ms [17:42] but that's already too late [17:43] I suppose my theory is that keeping things in kernel will reduce the time enough that it is more reliable [17:43] we'd need to confirm somehow the order of the events, is there anything we hear of in time even [17:43] * cnd wonders how we haven't seen this before [17:43] http://askubuntu.com/questions/91534/disable-touchpad-while-the-lid-is-down [17:44] sforshee, you might be able to use that to get a hint as to whether the lid closes before the problem happens if you arn't to quick :) [17:44] I bet because of behavior changes in X [17:44] so I'm pretty sure at this point it is the magnet, as I can hold a macbook pro close to the touchpad but not touching and get touchpad events [17:44] apw, that will only turn off the device at the X level [17:45] I also know I can suspend the machine without completely closing the lid [17:45] maybe that's good enough though [17:45] sforshee, you can evtest both the bcm5974 and the lid switch devices [17:46] and compare the timestamps [17:46] sforshee, when does the backlight go off relative to the problem occuring too [17:46] see how close they get with fast lid closures [17:46] it can be emi too, though i dunno much of which would be near where the magnets are [17:46] sforshee, what cnd suggests makes the most sense. [17:46] my friend could make his macbook reboot by putting his phone next to his computer, they can be pretty sensitive :D [17:46] lets see if they are in any sort of sensible order [17:46] apw, it goes off earlier -- there seems to be something else in play for the lid event [17:47] sforshee, what goes off earlier? [17:47] I can't make the machine suspend by holding the MBP closeby [17:47] cnd, the backlight [17:47] oh [17:47] sforshee, isn't that triggered by the lid event ? [17:47] * apw thinks we need the double evtest comparison [17:48] * sforshee is getting it right now [17:48] * cnd whipers [17:48] whispers... [17:48] I ruined it [17:51] the lid switch event happens first, by about 400 ms [17:51] ok so we at least have something to tell us when we need to ignore it [17:51] sforshee, including when you try to close it as fast as possible without breaking it? [17:51] sforshee, i assume it unhappens after the flood stops too yes? [17:51] cnd, I was just about to say, let me try again closing the lid as quickly as possible [17:51] sforshee: was the input periodic or just fast/seemingly random [17:52] ohsix, http://pastebin.ubuntu.com/911758/ [17:52] ohsix, its a bunch of fat fingers reported all over the touchpad [17:52] cnd, this feels very familiar you know, is the matrix broken ? [17:52] interesting, it could be the lcd [17:53] ohsix, i think experimentation says its the lid in some sense, which bit isn't so interesting [17:53] rats, now I start getting touchpad events about 7 ms before the lid event [17:53] ugh [17:53] sforshee, well ... remember we have to get them out into userspace [17:53] who puts the timestamps on them, the uspace daemon ? [17:53] apw, yes [17:54] but they're certainly very close [17:54] apw, that doesn't even matter now [17:54] the lid switch is occurring *after* the bad touches [17:54] cnd, where is the timestamp we see added [17:54] right but a magnet isn't going to capacitively couple with a touchpad, it may induce currents but only as it moves (no matter how strong it is) [17:54] apw, hmm? [17:54] I didn't understand the question [17:55] cnd, we have two streams of data with timestamps, who put the stamps on them, the kernel or the evtest app [17:55] apw, the kernel [17:55] apw, 7 ms seems long enough that I doubt they're getting reordered anyway [17:55] some heuristics in the touchpad firmware are probably going bonkers because it's coupling with something in the display [17:55] ohsix, yep i think we know that ... what we don't know is how to stop it [17:56] given the lid is not going to change compisition [17:56] right :] it's just not a magnet [17:56] you may be able to control SSC or something in the lcd panel that could affect it tho [17:57] sforshee, it may be worth looking for reports of whining on osx about closing the lid and it being bad [17:57] (if you do it fast) [17:57] btw, my MT sees touches even when the screen is off [17:57] ohsix, there seems to be a magnet in the lid that holds the lid down when it's closed [17:57] so merely turning the screen off isn't a fix either [17:57] so when you close the lid it will be moving, period [17:57] cnd: what model is it? [17:57] macbook air 4,1 [17:57] ohsix, I was playing with a magic trackpad and a macbook 5,1 (I think) [17:58] cnd, yeah wasn't thinking we want to turn off the screen, i was thinking we want to disable the touchpad [17:58]