[00:34] ogasawara: looks like -22.32 is missing the guard page change [00:58] kees: hrm, were there additional patches besides the one I mentioned earlier? [02:45] Hi everyone, I'm having a problem with a kernel module crashing when I attempt to modify the system call table. Which would be expected, except that I have made its page in memory writable before attempting this feat. Any ideas would be very much appreciated :) http://codepad.org/W3ThQbb8 [02:50] undriedsea: wow, interesting [02:51] lol, are you being sarcastic Ace? I know its not terribly complex, but it has me stumped [02:52] undriedsea: no, I never thought of you can modify sys_call_table by that way [02:52] undriedsea: are you just trying to catch calls to sys_open? [02:53] yes, but this is just a test. I have a bunch of system calls I need to hook into at a low level. LD linking is not good enough for me because apps could call the syscall directly and not use the C lib, and I need to handle that [02:54] undriedsea: there is a runtime patching system for the kernel some US guys wrote a few years back; they do this sort of thing and much more complex too - have a look into that [02:54] are you looking to modify the syscall's behaviour, or just monitor it? [02:55] in this test I am monitoring. I will be changed the behavior [02:55] *changing [02:55] I will take a look at that lifeless. I still, for my own sake, would really like to understand why my code does not work [02:57] undriedsea: also, you can still do this in userspace via ptrace() [02:58] thanks jk, I thought about that, but for the project the context switch overhead would kill performance [03:00] I realize this is the old/dirty way to intercept a syscall, but it is also very fast- and I can't think of why that code does not work. However, I must confess- I have not spent much time with this kernel [03:01] undriedsea: so what's the oops message you're seeing? [03:01] Sep 16 19:51:02 kdev kernel: [ 145.012726] BUG: unable to handle kernel paging request at ffffffff81551390 [03:01] that is the address of the system call table [03:02] or actually sys_call_table[__NR_open] [03:02] could you paste the rest of the log? [03:03] err, pastebin, not paste in the chan [03:03] sure http://codepad.org/O01qFsdz [03:04] Thank you for bothering to take a look :) [03:05] and what's the instruction at init_module+0x51 ? [03:06] (could you pastebin a disassembly of init_module?) [03:06] undriedsea: I got BUG: at set_memory_rw() function call [03:06] undriedsea: not OOPS [03:07] that is interesting, what is your platform? I am amd64 [03:07] Also, did you change the sys_call_table address to match your own system AceLan? [03:07] AceLan_: yeah, it's probably bugging in change_page_attr_set_clr, because the page address is not page-aligned [03:08] undriedsea: a normal i386 kernel [03:08] jk, can I use hexdump to do that? [03:08] undriedsea: sure, I changed the address [03:08] undriedsea: objdump -d [03:08] undriedsea: you're probably seeing that WARN_ON_ONCE too [03:09] jk: the dump http://codepad.org/FcHuSS0c [03:10] jk: do I need to make sure my call to set_memory_rw is 4k aligned? [03:12] undriedsea: it should be, but that's not what's causing the oops [03:12] also, are you sure that this disassembly matches the module that you inserted to cause this oops? [03:13] Maybe- I ran that objdump on the .o, should it have been on the .ko ? (n00b sorry...) [03:13] on the .o is fine [03:14] but the oops log reports that your init_module function is 0x70 bytes in size, whereas the disassemly would indicate that it's 0x49 bytes [03:14] undriedsea: read this # http://www.downloadpipe.com/forums/linux/Problem-set_memory_rw-ftopict76420.html [03:14] system call table is on .rodata section and set_memory_rw() doesn't [03:14] allow change attributes on .rodata sections(not .text) [03:14] my .ko dump is much larger [03:15] Thanks ace! [03:15] I guess I will have to modify the page table directly to accomplish my goal [03:16] :( [03:16] or patch sys_open [03:16] undriedsea: yes, you have to export sys_call_table [03:17] That would require my end users to install a custom kernel wouldn't it, rather than just install my module? [03:17] undriedsea: you have to modify the kernel :( [03:17] but this is all pretty ugly, what are you actually trying to do? [03:18] AceLan_: exporting it will only expose the linkage, will still be able to refer to it by symbol address [03:19] I am writing a process live migration module, I need to capture sys_calls and translate file handles, process IDs etc. For example, a process might get moved to a machine where its PID conflicts with an existing PID, so I need to hide this [03:19] If I was writing this 6 years ago before all this stop exporting the sys_call_table, make it RO nonsense, it would be much easier :) [03:20] wow, sounds so cool, process moves among machines [03:21] Well, I hope it is cool when I am done, or I will be working on my masters project a looong time lol :) [03:21] undriedsea: how about not real move the process, indtead of recreating the same one on another machine? [03:22] Those are the same things, I am doing two things, replicating the process state, and hiding namespace issues (file handle number, PIDs, semphore ids, etc) [03:23] I cannot change the PID even after moving becuase the programmer of the application may have made a call eariler to get the PID and their code might now be depending on that value [03:24] right, very reasonable [03:25] There are other methods besides doing what I am doing, but they are either slow (because the involve kernel/user-mode context switches) or they only capture syscalls made through the standard libraries (which means I could not migrate applications which directly make system calls) [03:26] undriedsea: have you to use 2.6 kernel? I think modify sys_call_table in 2.4 kernel is much easier [03:26] So I guess I will be directly changing the page table using the low level instructions because the kernel is silly and won't do it [03:26] You are correct, however, I want people to be able to do useful things with the result of my project [03:27] I could just make my own kernel build that turns the security off in 2.6 too, but ideally, I only want people to need to load a module (if at all possible) [03:29] undriedsea: what are you doing about kernel state - open files, sockets, etc? [03:30] replicating it [03:30] how? [03:32] By keeping track of kernel state of live migration processes and recreating that state on the new host. The unique identifier might not match, but my namespace translation later takes care of that [03:33] or will, I am just getting started [03:40] undriedsea: have you read Eric Roman's survey of Checkpoint/Restart implementations? [03:40] undriedsea: and Zhong and Nieh's CRAK paper? [03:42] CRAK and ZAP yes, I will look for Erics [03:43] I found the code that is killing me, 832 if (!pgprot_val(mask_set) && !pgprot_val(mask_clr) && !force_split) [03:43] 833 return 0; [03:43] http://lxr.linux.no/#linux+v2.6.31/arch/x86/mm/pageattr.c#L818 [03:44] you can control the fd table, so you don't need to worry about translating FDs [03:45] fd, file descriptors? [03:45] yep [03:45] cool, that will be nice [04:09] When looking at System.map, what do the single character values after the address and before the symbolic name denote? [04:44] undriedsea: The "How to get sys_call_table" and "Simple sys_call_table hook" might useful # http://www.slideshare.net/fisher.w.y/rootkit-on-linux-x86-v26 === BenC___ is now known as BenC [04:57] AceLan, that is very interesting, thank you === fddfoo is now known as fdd [08:20] diwic: Hi [08:21] Hi lag [08:21] I'm assuming you have a vast array of test audio files? [08:21] Do you have any S32_LE? [08:22] lag, naah, but use the plug layer and it will convert it for you [08:22] Okay [08:22] Cheers [08:22] I'll probably be pestering you a few times today - stay alert ;) [08:23] lag, or if that doesn't work, I can create one in audacity for you [08:23] Cool, thanks === diwic is now known as diwic_afk === amitk is now known as amitk-afk === diwic_afk is now known as diwic === makx_ is now known as maks_ [10:28] ogasawara, ping === diwic is now known as diwic_afk === amitk-afk is now known as amitk === diwic_afk is now known as diwic [13:03] diwic: Can you come into #ubuntu-arm? === bjf[afk] is now known as bjf [14:55] JFo: cranberry is now running lucid [14:55] excellent [15:01] bjf, I talked to takashi about his dailies, he said they were created after midnight, his time. So if you run your script approx UTC+3, that would be optimal [15:01] diwic, thanks, I can make that happen [15:02] bjf, great :-) [15:03] diwic, where does takashi live? [15:04] bjf, in Germany I believe. [15:05] bjf, which is UTC+1 +DST [15:05] diwic, ok, that puts him 9 hours ahead of me [15:06] bjf, and me as well then - amazing you're up already ;-) [15:06] diwic, UTC+2 [15:07] diwic, it's 7 a.m. already! where has the day gone? [15:07] smb, UTC+1 in winter and UTC+2 in summer, right? [15:07] right [15:07] same as here. [15:08] smb, you are from Germany as well, right? [15:08] I am, yes. I am never sure about Takasi thoug. :) [15:09] diwic, so his midnight should be my 15:00 [15:09] People tended to believe GregKH to be in Germany, too as he has a suse.de email address as well. [15:09] bjf, Its 4:10pm here if that helps [15:10] brb [15:11] smb, the math still works out :-) [15:13] diwic, time on the cron job has been adjusted [15:13] bjf, thumbs up [15:14] ogasawara, manjo: bug 641320 [15:14] Launchpad bug 641320 in linux (Ubuntu) "Touchpad is not working since last kernel update in maverick (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/641320 [15:15] due to the new ALPS patch [15:15] manjo, why did you push the dell patch instead of the patch on LP that had bug fixes in it? [15:15] cnd, I picked the patch from the LP [15:16] cnd, and jerone tested it at dell [15:16] oh, someone on the LP bug thought it wasn't that patch [15:16] they thought it was the upstream patch [15:17] either way, we probably need to revert the patch [15:17] perhaps one of you could confirm we didn't end up taking the upstream patch [15:17] cnd, :) heh funny coz you recommended that patch in the 1st place [15:17] heh, I pointed it out :) [15:18] it may have been assumed it was the same and that one cherry-picked instread [15:18] no recommendation [15:18] just that it has some fixes the dell one doesn't [15:18] btw, sorry if I'm a bit curt [15:18] in the middle of xds :) [15:18] cnd/manjo, which was the original bug [15:18] apw, I need to dig it out [15:19] http://bugs.launchpad.net/bugs/632884 [15:19] Launchpad bug 632884 in linux (Ubuntu) (and 1 other project) " Add support for Intellimouse Mode in ALPS touchpad on Dell Latitude series Laptops (affects: 1) (heat: 10)" [Undecided,Fix released] [15:19] manjo, cnd, this sounds like the problem davidm is also having [15:22] manjo, apw, the sauce patch in ubuntu doesn't match the LP patch [15:22] cnd which lp patch are you taking about ? [15:22] cnd, seems to match the 'final patch' link [15:23] The final patch can be found here: [15:23] https://patchwork.kernel.org/patch/118834/ [15:23] that is what I pushed [15:23] manjo, which is the upstream submitted dell patch I said not to use :) [15:24] cnd, I don't see any other patch there [15:24] manjo, it's on the LP bug [15:24] cnd: bug work right so soon after you get done with a talk? you're a machine! :) [15:24] heh [15:24] http://launchpadlibrarian.net/54076279/2.6.35-alps-730264-imps-emulation.patch [15:24] dammit this is serious, we have pushed the final maverick kernels [15:24] manjo, that's the patch I pointed to ^ [15:24] to get this fixed we need to get an exception [15:25] from https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/550625/comments/154 [15:25] Launchpad bug 550625 in linux (Ubuntu Lucid) (and 2 other projects) "Alps touchpad is recognized but synaptics clients and scrolling do not work (affects: 113) (dups: 9) (heat: 576)" [Medium,Incomplete] [15:25] bjf, does davidm have a bug also ? [15:25] * apw will switch the patch and get some test kernles out to these bugs [15:26] apw, yes, though he's been unable to actually file it due to LP timeouts [15:26] cnd, there is no mention of 550625 in 632884 so when you asked me to help with 632884 I did by picking up the final patch there [15:27] manjo, there is though in comment #1 [15:28] manjo, anyhow i'll get some kernels together [15:30] apw, might I suggest just pulling the patch? [15:30] git revert [15:30] the patch hasn't been reviewed upstream and we're so late [15:30] and the trackpads still work without the patch, just not with scrolling support [15:30] cnd, i thought you needed that in to get multi-touch or some shit [15:31] apw, nope [15:31] it was just a bug I wanted someone to look at [15:31] since I had seen someone in the community had worked on the patch some [15:31] I didn't want it to fall through the cracks [15:31] and disappear forever into LP :) [15:32] oh goodie, i get to blame manjo for breaking my tp :) [15:33] cnd, so why did you ask me to look at it if it was not important ? [15:33] * hallyn shakes his fist [15:33] I never said it was important :) [15:33] I just said someone should look at it [15:38] there are quite a large number of bugs against synaptics at least regarding the alps scroll situation that i'm moving over to that one right now, I wouldn't say its unimportant. not having touchpad scroll is a pretty crappy user experience [15:40] Sarvatt, it's not whether it's important or not [15:40] it's that we're in kernel freeze [15:40] and we aren't positive that we won't add more regressions with the patch from LP [15:41] Sarvatt, right, we really are past the point where we want to make any changes as someone has to respin every CD as a result [15:41] and we have no time to get any testing on it, i'll mark the bug for consideration after release [15:41] (the original one) and we can then test it more thoroughly [15:44] my hope was that someone would take a look at the LP patch many weeks ago, put it in a development kernel, and then we can work on upstreaming it [15:45] then oem services wanted proper alps support, and manjo and vanhoof looked at it a week or two ago [15:45] timing just wasn't as good as one could hope :( [15:45] and I didn't have enough time to work the bug properly myself... [15:46] JFo: ping [16:00] robbiew, pong [16:01] s'what I get for working on 2 machines [16:02] JFo: nevermind...was going to ask you about I bug, but I decided it was easier to just ask the submitter as a comment ;) [16:03] heh [16:10] hallyn, hey ... i'm just reverting that patch and will have some test kernels in about 10 mins for testing if you could confirm the revert fixes you [16:10] apw: cool [16:13] * JFo stepping out for a bit. some errands and packing to complete before flying for Taipei tomorrow. [16:19] kees: about? want to check back with you about the stack guard change you said was missing? [16:20] kees: I'd only applied the one patch from smb - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=1ccc5359a8f055b153a2e0cfec02a594a8443360 [16:21] kees: is there additional patches I need to get applied? [16:24] jjohansen: re "[PATCH 3/3] UBUNTU: SAUCE: AppArmor: allow newer tools to load policyon older kernels" [16:24] jjohansen: is there something you want modified with that patch per tetsuo's comments? [16:24] apw: actually gotta run for a bit, i'll test when i get back [16:25] jjohansen: we might have a chance to get that fixed and squeezed into a last minute upload [16:25] ogasawara: let me check if it passes now that I've rebooted [16:25] ogasawara: doesn't seem to pass [16:26] smb: the test still fails on maverick with that applied ^^ [16:26] kees, hm... [16:26] oh wait [16:26] I'm still on the wrong kernel, one sec [16:27] * smb holds his breath [16:27] * ogasawara crosses fingers the right kernel works [16:27] * smb turns slightly purple... [16:27] kees@sec-maverick-i386:~/qa-regression-testing/scripts/kernel/guard-page$ cat /proc/version_signature [16:27] Ubuntu 2.6.35-22.32-generic 2.6.35.4 [16:27] kees@sec-maverick-i386:~/qa-regression-testing/scripts/kernel/guard-page$ ./split-stack stack start changed due to mlock call (0xbfa2c000 != 0xbfa4b000)! [16:27] still fails [16:28] kees, is there more output to look at? [16:28] fails on hardy even. *scratch head* [16:28] kees: how critical is this for landing in Maverick's release? [16:29] kees: as we've likely got one last shot for an upload [16:29] I would say not very critical [16:29] smb: so it could potentially be resolved via an SRU post maverick release? [16:29] Yes, sounds reasonable [16:29] * kees will boot an upstream vanilla kernels [16:30] s/s$// [16:30] kees, But those addresses seem to be too far apart to be one page... [16:30] kees, Thats weird [16:30] Do you have the full output of maps somewhere? [16:30] smb: it goes from: [16:30] bff13000-bff34000 rw-p 00000000 00:00 0 [stack] [16:31] to: [16:31] bff13000-bff33000 rw-p 00000000 00:00 0 [16:31] bff33000-bff34000 rw-p 00000000 00:00 0 [stack] [16:31] across the mlock call [16:31] kees, There does not seem to be a whole in there to me [16:31] err hole [16:32] hm? but the thing that got called "stack" got chopped up [16:32] maybe I misunderstood the issue? [16:32] I suppose [16:32] wron would be [16:32] bff13000-bff33000 rw-p 00000000 00:00 0 [16:33] errr what would be bff333000 +4k. === tgardner is now known as tgardner-afk [16:34] ogasawara: yes, if we can squeeze it in [16:34] kees, Seems to be an unfortunate example [16:34] jjohansen: yep, just get me a patch to the ml asap [16:34] ogasawara: okay [16:34] The problem _was_ that you saw a gap between the vmas [16:34] smb, 4k == 1000 hex [16:35] apw, ta [16:35] 7fff810d6000-7fff810f7000 rw-p 00000000 00:00 0 [stack] [16:35] vs [16:35] 7fff810d6000-7fff810f5000 rw-p 00000000 00:00 0 [16:35] 7fff810f6000-7fff810f6000 rw-p 00000000 00:00 0 [stack] === yofel_ is now known as yofel [16:35] smb: there's a gap between 7fff810f5000 and 7fff810f6000 [16:35] is that the bug? [16:35] my testcase is wrong, I guess. [16:36] * smb scratches his head [16:36] I thought it was the fact that the stack got misidentified [16:36] kees, That looks more broken than anything I saw [16:36] jjohansen: if you prefer, just give me two patches, one to revert the original SAUCE patch and then the fixed up version [16:37] ogasawara: okay [16:38] kees, The problem was that the first page of a stack vma got hidden (start was moved up one page). [16:39] that would seem to be what the "gap between 7fff810f5000 and 7fff810f6000" demonstrates [16:39] kees, May be what you posted last. 6000-6000 (basically size 0) [16:40] The 6000-5000 looks really weird [16:40] smb, thats doesn't say 6000->5000 [16:41] okay, the kernels before the guard page show: [16:41] bfdd1000-bfde6000 rw-p 00000000 00:00 0 [stack] [16:41] into [16:41] bfdd1000-bfde3000 rw-p 00000000 00:00 0 [16:41] bfde3000-bfde4000 rw-p 00000000 00:00 0 [stack] [16:41] it says d6000->f5000 [16:41] so the split is "ok". it's the _gap_ that is bad. [16:41] apw, ah ok missed that [16:42] I'll fix the test case [16:42] kees, But the second exapmple has no gap, right? bfdd1000-bfde3000 and bfde3000-bfde4000 [16:42] kees, oh ah [16:42] kees, yes [16:43] * kees nods [16:43] kees, the split is ok. but the address range should be connected [16:43] I thought the bug was the splitting at all. I didn't realize the gap [16:43] right [16:43] fixing testcase... [16:43] it always has to be split cause the permissions differ after the mlock [16:44] apw: though oddly, the state of mlock isn't shown in maps [16:44] (nor vma growth direction) [16:44] kees, indeed, maps is a little useless [16:45] kees, might be more in smaps [16:45] apw: it seems that the following commit was included after 2.6.35-20: [16:45] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c41d68a513c71e35a14f66d71782d27a79a81ea6 [16:45] apw: this breaks fglrx [16:46] compat_alloc_user_space(), that is [16:46] tseliot, how does it manifest, what breaks [16:47] apw: I get error: implicit declaration of function ‘compat_alloc_user_space’ [16:47] apw: when trying to build the kernel module for fglrx [16:47] tseliot, ITs likely because they exported thy symbol GPL [16:47] tseliot, try converting the call to arch_compat_alloc_user_space() [16:48] EXPORT_SYMBOL_GPL(compat_alloc_user_space) [16:48] ahh ... doh [16:48] apw, smb: I could use arch_compat_alloc_user_space() but would this work on previous 2.6.35 kernels? [16:48] ogra, mpoirier: bug 630885, is that release critical? or ok as a post release SRU? [16:48] Launchpad bug 630885 in linux (Ubuntu) (and 1 other project) "Preinstalled Maverick netbook image has no display on omap3 EVM (no LCD) (affects: 1) (heat: 14)" [Undecided,In progress] https://launchpad.net/bugs/630885 [16:48] tseliot, nope [16:49] apw: it was a rhetorical question ;) [16:49] ogasawara, we dont have such HW in the team, probably for linaro [16:49] ogasawara, but since i expect changes for omap3 anyway it wouldnt do harm to have it too [16:49] smb: do you mean to say that they did EXPORT_SYMBOL_GPL(compat_alloc_user_space) in the fglrx code? [16:50] tseliot, No they made the export like that in kernel/compat.c [16:50] Before that it was an inline function [16:50] tseliot, no he is saying the kernel has been changed to only export it to GPL stuff [16:50] smb: ah, I get it now [16:50] ogasawara: the request came from a TI guy - is we get it in great, otherwise that's just life. [16:51] tseliot, sounds like you have just need to include a header though [16:51] as the code you are compiling is GPL right, the shim is GPL [16:51] mpoirier: and the patch itself is going upstream? [16:51] ogasawara: I wish it could... [16:52] but haven't had any luck with all our beagle work. [16:52] mpoirier: tgardner had inquired [16:52] tseliot, yeah, mabe including works [16:52] yes, tgardner and I have talked about it. [16:53] apw, smb: including works but I can't because it's GPL while the file that should include it is not [16:53] ogasawara: I'm thinking about enlisting outside key contributors to help with the push up. [16:53] mpoirier: might be good to post the result of the discussion to the mailing list so we're all in the loop [16:54] tseliot, add a shim funtion in the gpl file ? [16:54] mpoirier: and I assume I should add the additional provenance for the patch? [16:54] ogasawara: should we mumble ? [16:54] mpoirier: sure [16:58] I've been playing with compiling the kernel and trying to figure it out on that level. I got myself stuck though. I'm missing a module (I assume) but I have no idea what module it might be.. My system boots pretty nice. It even loads to TTY7 (only 1 and 7). This is what I wind up seeing. http://pastebin.ubuntu.com/495371/ (Maverick). Any chance I could get a little pointer? === amitk is now known as amitk-afk [17:03] ogasawara: patches should be on the list now [17:03] jjohansen: great, thanks [17:05] apw: ah, so a simple function that calls arch_compat_alloc_user_space() in asm/compat.h? [17:07] tseliot, I probably would rather do a simple function that call compat_alloc_userspace (to get the benefit of the additional checks) which is defined in a gpl'ed code [17:10] tseliot, indded as smb suggests [17:10] fgrlx_alloc_user_space() { compat_aloc_user_space() } [17:10] stylee [17:10] and that should be compatible either way i think [17:11] thus showing how stupid the whole export_gpl stuff really is, as you can comply with the rules [17:17] apw, smb: ah, so I could add that function in asm/compat.h and the thing would be legal? This would mean adding something like #define ALLOC_COMPAT_LEGACY (or a better name) so that fglrx can see whether it needs to call fgrlx_alloc_user_space() at build time. [17:18] No, not changing anything in the normal kernel code. This should go into the fglrx code (the part that is gpl) [17:21] smb: this is what they currently do in fglrx: [17:21] void* ATI_API_CALL KCL_IOCTL_AllocUserSpace32(long size) [17:21] { [17:21] return compat_alloc_user_space(size); [17:21] } [17:21] and they do that in non-GPL file right ? [17:21] yep [17:21] but they ahve a GPL file, so change that to fgrlc_alloc....(size) [17:21] and add an identicle wrapper to the GPL file [17:22] as i say, the separation is pointless [17:23] hallyn, kernel for testing is at: http://people.canonical.com/~apw/lp641320-maverick/ [17:24] tseliot, do u mumble ? [17:24] apw: yep but I need to connect the microphone [17:24] might be easier to talk [17:27] apw: right but my microphone doesn't seem to be detected... [17:28] * tseliot blames it on pulseaudio [17:30] Is there a ureadahead module in the ubuntu version of the kernel that's required to boot - even if you don't have ureadahead? [17:34] apw: ok, it works now, let's talk [17:37] apw: where shall we talk? [17:38] we are in cafinated conversation ... under Kernel [17:38] tseliot, kernel teams caffeinated conversation [17:39] smb, apw: ok, I'm there [17:43] apw: can you hear me? [17:43] He cannot [17:43] oh [17:43] In fact none of us. :) [17:43] ok, let me reconfigure mumble [17:47] smb, apw: now it's telling me that my password is wrong. I'll give up on mumble for now. [17:47] apw, smb: were you suggesting that I define the function in the GPL file and export the function? [17:48] the fgrlx_alloc_user_space() function that is [17:48] Right, you do it in the GPL file and export it (or link) it to the non-gpl file [17:49] ok, I see what you mean now [17:49] thanks [17:56] smb, apw: thanks a lot for your help [17:56] np :) [17:58] apw: that kernel is good [17:58] hallyn, thanks can you update the bug pls [18:00] apw: done, thanks [18:05] though now, periodically the x display just hange. right now i'm typing typing typing and not seeing anything, but i'tll suddenly just catch up maybe [18:19] apw: http://pastebin.ubuntu.com/495420/ [18:39] apw: http://pastebin.ubuntu.com/495429/ - updated revision [18:54] would something like this work for all of these vaio F series that need i8042.nopnp? http://sarvatt.com/downloads/patches/vaio-vpcf-i8042-quirk.patch [18:56] VPCF1290X VPCF126FM VPCF12S1E VPCF12M1E VPCF121FD are the models i've found so far needing it [18:57] Given that Windows uses pnp to identify i8042 devices, that seems very much like the wrong fix [19:08] mjg59: thanks, it was a shot in the dark. it looks to be all VPCF12xxx devices, VPCF11xxx that hallyn has doesn't need the quirk to have the touchpad working [19:08] Sarvatt: What's the bug number for this? [19:08] Sarvatt: And does it have dmesg in both cases? [19:09] there are a whole rack of bugs i'm noticing now that i'm looking and haven't condensed them yet, one sec i'll get you a list. they all have this in dmesg [19:09] [ 1.377980] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [19:09] [ 1.377982] PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [19:10] Awesome [19:10] Sarvatt: Need acpidump as well [19:10] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/636638 [19:10] Ubuntu bug 636638 in linux (Ubuntu) "Touchpad is not detected on Sony VPCF126FM (affects: 1) (heat: 848)" [Undecided,New] [19:11] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/641169 [19:11] Ubuntu bug 641169 in linux (Ubuntu) "alps touchpad sony vaio recognized, but not working (affects: 1) (heat: 6)" [Undecided,New] [19:11] ^ that one has acpidump but no dmesg, he put his dmesg in another bug [19:11] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/638219 [19:11] Ubuntu bug 638219 in linux (Ubuntu) "Touchpad does not work on Sony Vaio VPCF12M1E (affects: 1) (heat: 1692)" [Undecided,New] [19:11] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/636842 [19:11] Ubuntu bug 636842 in linux (Ubuntu) "Touchpad not found on Sony Vaio VPCF12S1E (affects: 1) (heat: 6)" [Undecided,New] [19:12] sorry for the spam [19:12] Sarvatt: I think 641169 is different [19:12]