[00:12] hi, did anybody port snd-bt-sco to 2.6.28 yet? [00:12] that's been deprecated for a long time [00:13] and is the new varinat working or not [00:13] as that required a kernel patch too [00:13] works for me [00:14] whats the package with the client tool [00:17] bluez... at least in jaunty [00:18] will take a look [09:27] hello. === asac_ is now known as asac [13:28] hi rtg [13:29] Kano: 'morning [13:29] are you working on 2.6.28.2 yet? [13:30] yep, just haven't pushed it yet as its an ABI bump [13:30] rtg: when do you expect to push? [13:30] i know, i have got a new alsa workaround [13:30] just need to find the correct postition [13:30] who was the alsa maintainer here? [13:31] amitk: likely today. I'm traveling beginning Wednesday, so if I don't get it started soon, I won't get all the packages uploaded in time. [13:31] Kano: what is the alsa workaround? [13:32] http://www.alsa-project.org/db/?f=bf479d3ab19f7ac37f7c1a17d4d4210de8fe5e1c [13:32] this system needs model=laptop [13:32] to get the mic working [13:33] Kano: you need to talk to TheMuso about patches in user space. [13:34] i created other alsa patches already, just to need to remember the correct postition [13:34] sometimes it is easy when you can use other patches as example [13:37] you still have got snd-bt-sco in media but not enabled it seems [13:38] well it must be in connexant file it seems [13:40] will test it [13:41] there are already some other hp workarounds in there [13:47] <`emgent`> BenC: around ? [13:49] <`emgent`> there is a critical problem in hardy kernel, some times dhcp association with ethernet card (driver r8169) work and some times not.. i found a fix in kernel.org GIT [13:49] <`emgent`> http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=523a609496dbc3897e530db2a2f27650d125ea00;hp=e93dcb11dd6468000f2f018bd887e94b074ce931 [13:49] <`emgent`> someone can take a look ? [13:49] http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff [13:49] most likely that,but will do a test [13:50] <`emgent`> kanotix ? [13:50] <`emgent`> O_o [13:51] <`emgent`> BenC: anyway when you have time take a look danke. [13:53] rtg: can you push it now? i dont want to compile -5 kernel and then -6 again... [14:03] `emgent`, Do you have a lp bug number for that? [14:05] <`emgent`> smb_tp_: no, and i dont have a lp account here. [14:05] <`emgent`> i'm at work and i'm involved in a project based on ubuntu hardy. [14:05] <`emgent`> so, i found bug and fix.. [14:08] amitk: I pushed 2.6.28-6.16. How long does it take you to test build an ARM kernel? [14:08] `emgent`, do you have an account privately? if not I file one but it would be good if you could then mail me a bit more information about it. [14:09] rtg: thanks, will add my patch and compile [14:10] NCommander: whats the story on this ARM kexec patch that Rusty is objecting to? [14:14] rtg: too long [14:14] rtg: are there config changes? [14:15] amitk: ok, I'll just take a chance that ARM will actually compile. it takes me about 10 hours to build a test kernel. [14:15] <`emgent`> smb_tp_: ya i have an account. I'm Master Of Universe Ubuntu Devel. [14:15] wasn't infinity giving us a porter machine or two [14:15] amitk: no config chnages that I'm aware of. [14:15] amitk: yes, I thought the porter was gonna be ready any day now. [14:16] amitk: do you have an opinion on this kexec patch that I took on faith from NCommander? Is it really borked as Russel says? [14:17] `emgent`, Great, if you could create a report later and assign it to me stefan-bader-canonical, so we have something to track the stable updates process, that would be awesome. [14:17] <`emgent`> ya will do when i'm back to home. [14:17] rtg: yes. Which is why I forwarded it to arm list for comments. I would say, revert it for now. [14:18] <`emgent`> smb_tp_: danke. [14:18] `emgent`, bitte [14:18] amitk: done. I thought it had been tested and worked. [15:03] hi guys, I need to make my helloWorld driver works on my kernel, its version is 2.6.27-9, it should printk helloworld at the module init, I guess it is the version dependency [15:04] could someone help me [15:16] i 'd like to write a module wich is intended to work in multiple versions of the kernels , how do I solve the version dependency???? [15:20] You can't build a module that will work with all kernel versions [15:20] It has to be recompiled against the target kernel [15:24] yeap, but there are macros that make it possible, not for all kerns, but for some of them... [15:24] so I dont know what is wrong with my sourcecode [15:25] it should at least print hello [15:26] printk( KERN_ALERT "HELLO") [15:42] looks to be missing a ; [15:49] no man, not becouse of that [16:15] so what does it say when you try and use it [16:31] hey [16:32] i havy a qustion about a driver [16:32] that i want to be added [17:25] rtg: do you remember the kernel patch for alsa? it is verified now [17:27] Kano: there have been about a zillion alsa patches. which one in particular did you have in mind? [17:27] http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff [18:45] cking, yeah i agree, and telling the size of each set is tricky [18:46] apw: perhaps a recap of the points is required? [18:46] my gut is that if the other os does it that way we are less likely to have regressions turning it on, than if it did no [18:46] indeed [18:47] so we have a some recently released amchines which have synaptics touchpads [18:47] when we suspend and resume those touchpads get lost, not reinitialised correctly [18:47] bus analysis shows we are not resetting the auxillary ps/2 bus before trying to reaquire them [18:47] and this is preventing them from being picked up [18:48] other ps/2 mouse drivers commonly do reset before reaquiring the device on resume [18:48] and it is suggested that drivers for other OSs do the same [18:48] ... [18:48] the question outstanding is how to add this reset where it is needed without breaking the existing user set [18:48] options are: [18:49] 1) enable it on the assumption it is benign and offer a module option/dmi list to disable it where this is wrong [18:49] 2) leave it disabled, and add an option to enable it when required [18:49] ... [18:50] to my mind if it is true that commonly other OSs reset first then this should be low risk, but it is hard to know for sure [18:50] so one option would be to enable this for Jaunty with an override available and see who hollers [18:51] the basic question is which set is larger the set which are happy with a reset or those which will break with it [18:51] It is something that we only know if we get a suitable amount of alpha testing [18:51] we have two sets of information [18:52] 1) noone has complained before and we do not have it now in our kerenls [18:52] 2) the other OSs do do it [18:52] my guess would be, that with 2) there never will be known whether the assumption is true because who will enable an option if nothing is wrong [18:52] how badly will be the bad case is the question? [18:52] yeah, going 2) is the safe route but will never tell us the answer [18:52] This is a dilemma. [18:52] well we might regress all synaptics touchpads out there [18:53] i think smb_tp_'s point is quite compelling, if we go 2) we will never ever know [18:53] if we go 1) we get shouted at an go 2) if we were wrong [18:53] So the worst that happens is that a lot of touchpads might not work unless an option is given... [18:53] so 1) is higher risk, but lower maintenance [18:53] that would be the worst case yes [18:54] planning on having a 'disable the new reset' option available [18:54] votes? [18:54] I am convinced that option 1) is a good idea as we have heard that other OS's do it that way [18:54] i feel 1) for now, with 2 as a fall back [18:54] Hm, what about an printk to say "if your touchpads goes on strike use this option"? [18:55] smb_tp_, we could do that [18:55] if we believe people look at dmesg of course [18:55] release notes perhaps too if it makes it to release [18:55] smb_tp_: well we will see it when they report a bug :-) [18:55] That would remove searching for users. And we could say please mail to us if that is not working. So we know whether this hits [18:56] Also, the extra port write should be relatively benign [18:56] apw, Release notes yes. Unfortunately who really really reads them? ;-) [18:56] heh noone of course [18:57] apw: This is a good opportunity to try it - it's not an SRU fix which could mess up a whole load more [18:58] Personally I would vote for 1) with a printk. It is nothing critically that renders a machine unusable. With the print it will be pretty obvious what ifs wrong if it goes wrong. [18:58] Very try - it will be catagorised as a suspend/resume regression. [18:58] Actually for Jaunty it is not a SRU, yet [18:58] s/try/true/ [18:59] rtg, What would you think? [19:00] ok i think we have a concensus here. that 1) with option to turn it off and a printk warning when its on [19:01] apw: I'm happier with that now we've thought it through [19:01] i think if i pencil in the dmi matching code, then switching the default would be a trivial 1 bit change to the patch should it be deemed crap by release [19:02] apw: good call [19:02] * smb_tp_ nods [19:03] smb_tp_: what do I think about what? [19:03] ok i'll take that as the plan, and if rtg changes things, its only a 1 bit change still [19:03] * rtg is ripping his hair over CRDA. [19:03] rtg, About what we discuss here. Its is something for Jaunty you know. :) [19:04] smb_tp_: and you want me to read 47 minutes of scroll back? [19:04] the short summary is that some synaptics touchpads do not work following resume if they are not reset first, the other OS apparently does so we do not [19:05] didn't I already see a patch for that? [19:05] you are kidding? [19:05] so the options are we add it and allow it to be disabled, or we allow it to be enabled, but the belief is all new synatics will need it [19:05] where did you see a patch for that? [19:06] I think it came from Mario at Dell. It might already be in the Jaunty tree [19:06] * apw checks, but i am using very recent jaunty kernels [19:06] mario did file the bug which you would have had email from too [19:06] apw: It'll come to me eventually. [19:07] nothing since july in those drivers (patch wise) [19:07] he has been hastling about it as some of their machines are affected [19:08] nothinhg in Hardy or Intrepid? [19:08] and I've been drowning in "Critical" issues to fix it so I passed it to apw [19:08] and its 'hassle', no T [19:09] * apw goes check [19:10] * cking notes that the problem with dictionaries is that one needs to be able spell correctly to be able to look up the word you need to check [19:11] indeed. and that if you are dyslexic at all then you can't even see the error [19:12] apw: whats the only thing I ever hassle you about :) [19:12] there is no obvious difference in reset handling from hardy to jaunty [19:12] so it must be something else related i guess [19:12] heh ... not using this channel? [19:13] maybe I was hallucinating, but I sure thought I remembered a touchpad reset patch. [19:13] I believe you're talking about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317270 [19:13] Malone bug 317270 in linux "Dell Studio XPS 16 touchpad doesn't return from resume" [Medium,In progress] [19:13] anyway, a DMI based reset is fine with me. [19:14] rtg the main question is the default, on or off [19:14] we should annoy upstream with it as well. they might have some thoughts. [19:14] we are tending to on for jaunty [19:14] yes if we wanted to defualt on, upstream would be the first place i'd wanna send it [19:15] default to off for Intrepid preserving current behavior? [19:15] we have been only asked for Jaunty [19:15] so i wouldn't be looking to modify there, but i guess off if it went there [19:15] and on in jaunty [19:15] go for it then. we have time to find regressions. [19:15] thanks all, i call that concensus [19:49] Hi, I've got a repeatable bug in the UDF filesystem that enables me to crash my box at will [19:49] If you create a file with illegal utf-8 filename and copy it over to a writeable udf filesystem you panic the box [19:49] ch05en: report a bug and mark it as a security vulnerability [19:49] ok [19:50] i'd say ;) [20:23] any plan to move to 2.6.29 for Jaunty? [20:24] no plans