Kano | hi, did anybody port snd-bt-sco to 2.6.28 yet? | 00:12 |
---|---|---|
johanbr | that's been deprecated for a long time | 00:12 |
Kano | and is the new varinat working or not | 00:13 |
Kano | as that required a kernel patch too | 00:13 |
johanbr | works for me | 00:13 |
Kano | whats the package with the client tool | 00:14 |
johanbr | bluez... at least in jaunty | 00:17 |
Kano | will take a look | 00:18 |
emgent`` | hello. | 09:27 |
=== asac_ is now known as asac | ||
Kano | hi rtg | 13:28 |
rtg | Kano: 'morning | 13:29 |
Kano | are you working on 2.6.28.2 yet? | 13:29 |
rtg | yep, just haven't pushed it yet as its an ABI bump | 13:30 |
amitk | rtg: when do you expect to push? | 13:30 |
Kano | i know, i have got a new alsa workaround | 13:30 |
Kano | just need to find the correct postition | 13:30 |
Kano | who was the alsa maintainer here? | 13:30 |
rtg | 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 |
rtg | Kano: what is the alsa workaround? | 13:31 |
Kano | http://www.alsa-project.org/db/?f=bf479d3ab19f7ac37f7c1a17d4d4210de8fe5e1c | 13:32 |
Kano | this system needs model=laptop | 13:32 |
Kano | to get the mic working | 13:32 |
rtg | Kano: you need to talk to TheMuso about patches in user space. | 13:33 |
Kano | i created other alsa patches already, just to need to remember the correct postition | 13:34 |
Kano | sometimes it is easy when you can use other patches as example | 13:34 |
Kano | you still have got snd-bt-sco in media but not enabled it seems | 13:37 |
Kano | well it must be in connexant file it seems | 13:38 |
Kano | will test it | 13:40 |
Kano | there are already some other hp workarounds in there | 13:41 |
`emgent` | BenC: around ? | 13:47 |
`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 |
Kano | http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff | 13:49 |
Kano | most likely that,but will do a test | 13:49 |
`emgent` | kanotix ? | 13:50 |
`emgent` | O_o | 13:50 |
`emgent` | BenC: anyway when you have time take a look danke. | 13:51 |
Kano | rtg: can you push it now? i dont want to compile -5 kernel and then -6 again... | 13:53 |
smb_tp_ | `emgent`, Do you have a lp bug number for that? | 14:03 |
`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:05 |
rtg | amitk: I pushed 2.6.28-6.16. How long does it take you to test build an ARM kernel? | 14:08 |
smb_tp_ | `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:08 |
Kano | rtg: thanks, will add my patch and compile | 14:09 |
rtg | NCommander: whats the story on this ARM kexec patch that Rusty is objecting to? | 14:10 |
amitk | rtg: too long | 14:14 |
amitk | rtg: are there config changes? | 14:14 |
rtg | 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 |
amitk | wasn't infinity giving us a porter machine or two | 14:15 |
rtg | amitk: no config chnages that I'm aware of. | 14:15 |
rtg | amitk: yes, I thought the porter was gonna be ready any day now. | 14:15 |
rtg | 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:16 |
smb_tp_ | `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 |
amitk | rtg: yes. Which is why I forwarded it to arm list for comments. I would say, revert it for now. | 14:17 |
`emgent` | smb_tp_: danke. | 14:18 |
smb_tp_ | `emgent`, bitte | 14:18 |
rtg | amitk: done. I thought it had been tested and worked. | 14:18 |
MalikLamin | 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:03 |
MalikLamin | could someone help me | 15:04 |
MalikLamin | 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:16 |
mjg59 | You can't build a module that will work with all kernel versions | 15:20 |
mjg59 | It has to be recompiled against the target kernel | 15:20 |
MalikLamin | yeap, but there are macros that make it possible, not for all kerns, but for some of them... | 15:24 |
MalikLamin | so I dont know what is wrong with my sourcecode | 15:24 |
MalikLamin | it should at least print hello | 15:25 |
MalikLamin | printk( KERN_ALERT "HELLO") | 15:26 |
apw | looks to be missing a ; | 15:42 |
MalikLamin | no man, not becouse of that | 15:49 |
apw | so what does it say when you try and use it | 16:15 |
DGMurdockIII | hey | 16:31 |
DGMurdockIII | i havy a qustion about a driver | 16:32 |
DGMurdockIII | that i want to be added | 16:32 |
Kano | rtg: do you remember the kernel patch for alsa? it is verified now | 17:25 |
rtg | Kano: there have been about a zillion alsa patches. which one in particular did you have in mind? | 17:27 |
Kano | http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff | 17:27 |
apw | cking, yeah i agree, and telling the size of each set is tricky | 18:45 |
cking | apw: perhaps a recap of the points is required? | 18:46 |
apw | 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 |
apw | indeed | 18:46 |
apw | so we have a some recently released amchines which have synaptics touchpads | 18:47 |
apw | when we suspend and resume those touchpads get lost, not reinitialised correctly | 18:47 |
apw | bus analysis shows we are not resetting the auxillary ps/2 bus before trying to reaquire them | 18:47 |
apw | and this is preventing them from being picked up | 18:47 |
apw | other ps/2 mouse drivers commonly do reset before reaquiring the device on resume | 18:48 |
apw | and it is suggested that drivers for other OSs do the same | 18:48 |
apw | ... | 18:48 |
apw | the question outstanding is how to add this reset where it is needed without breaking the existing user set | 18:48 |
apw | options are: | 18:48 |
apw | 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 |
apw | 2) leave it disabled, and add an option to enable it when required | 18:49 |
apw | ... | 18:49 |
apw | 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 |
apw | so one option would be to enable this for Jaunty with an override available and see who hollers | 18:50 |
apw | 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 |
cking | It is something that we only know if we get a suitable amount of alpha testing | 18:51 |
apw | we have two sets of information | 18:51 |
apw | 1) noone has complained before and we do not have it now in our kerenls | 18:52 |
apw | 2) the other OSs do do it | 18:52 |
smb_tp_ | 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 |
smb_tp_ | how badly will be the bad case is the question? | 18:52 |
apw | yeah, going 2) is the safe route but will never tell us the answer | 18:52 |
cking | This is a dilemma. | 18:52 |
apw | well we might regress all synaptics touchpads out there | 18:52 |
apw | i think smb_tp_'s point is quite compelling, if we go 2) we will never ever know | 18:53 |
apw | if we go 1) we get shouted at an go 2) if we were wrong | 18:53 |
smb_tp_ | So the worst that happens is that a lot of touchpads might not work unless an option is given... | 18:53 |
apw | so 1) is higher risk, but lower maintenance | 18:53 |
apw | that would be the worst case yes | 18:53 |
apw | planning on having a 'disable the new reset' option available | 18:54 |
apw | votes? | 18:54 |
cking | I am convinced that option 1) is a good idea as we have heard that other OS's do it that way | 18:54 |
apw | i feel 1) for now, with 2 as a fall back | 18:54 |
smb_tp_ | Hm, what about an printk to say "if your touchpads goes on strike use this option"? | 18:54 |
apw | smb_tp_, we could do that | 18:55 |
apw | if we believe people look at dmesg of course | 18:55 |
apw | release notes perhaps too if it makes it to release | 18:55 |
cking | smb_tp_: well we will see it when they report a bug :-) | 18:55 |
smb_tp_ | 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:55 |
cking | Also, the extra port write should be relatively benign | 18:56 |
smb_tp_ | apw, Release notes yes. Unfortunately who really really reads them? ;-) | 18:56 |
apw | heh noone of course | 18:56 |
cking | apw: This is a good opportunity to try it - it's not an SRU fix which could mess up a whole load more | 18:57 |
smb_tp_ | 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 |
cking | Very try - it will be catagorised as a suspend/resume regression. | 18:58 |
smb_tp_ | Actually for Jaunty it is not a SRU, yet | 18:58 |
cking | s/try/true/ | 18:58 |
smb_tp_ | rtg, What would you think? | 18:59 |
apw | ok i think we have a concensus here. that 1) with option to turn it off and a printk warning when its on | 19:00 |
cking | apw: I'm happier with that now we've thought it through | 19:01 |
apw | 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:01 |
cking | apw: good call | 19:02 |
* smb_tp_ nods | 19:02 | |
rtg | smb_tp_: what do I think about what? | 19:03 |
apw | 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 | |
smb_tp_ | rtg, About what we discuss here. Its is something for Jaunty you know. :) | 19:03 |
rtg | smb_tp_: and you want me to read 47 minutes of scroll back? | 19:04 |
apw | 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:04 |
rtg | didn't I already see a patch for that? | 19:05 |
cking | you are kidding? | 19:05 |
apw | 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 |
apw | where did you see a patch for that? | 19:05 |
rtg | 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 | |
apw | mario did file the bug which you would have had email from too | 19:06 |
rtg | apw: It'll come to me eventually. | 19:06 |
apw | nothing since july in those drivers (patch wise) | 19:07 |
apw | he has been hastling about it as some of their machines are affected | 19:07 |
rtg | nothinhg in Hardy or Intrepid? | 19:08 |
cking | and I've been drowning in "Critical" issues to fix it so I passed it to apw | 19:08 |
rtg | and its 'hassle', no T | 19:08 |
* apw goes check | 19:09 | |
* 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:10 | |
apw | indeed. and that if you are dyslexic at all then you can't even see the error | 19:11 |
rtg | apw: whats the only thing I ever hassle you about :) | 19:12 |
apw | there is no obvious difference in reset handling from hardy to jaunty | 19:12 |
apw | so it must be something else related i guess | 19:12 |
apw | heh ... not using this channel? | 19:12 |
rtg | maybe I was hallucinating, but I sure thought I remembered a touchpad reset patch. | 19:13 |
johanbr | I believe you're talking about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317270 | 19:13 |
ubot3 | Malone bug 317270 in linux "Dell Studio XPS 16 touchpad doesn't return from resume" [Medium,In progress] | 19:13 |
rtg | anyway, a DMI based reset is fine with me. | 19:13 |
apw | rtg the main question is the default, on or off | 19:14 |
rtg | we should annoy upstream with it as well. they might have some thoughts. | 19:14 |
apw | we are tending to on for jaunty | 19:14 |
apw | yes if we wanted to defualt on, upstream would be the first place i'd wanna send it | 19:14 |
rtg | default to off for Intrepid preserving current behavior? | 19:15 |
apw | we have been only asked for Jaunty | 19:15 |
apw | so i wouldn't be looking to modify there, but i guess off if it went there | 19:15 |
apw | and on in jaunty | 19:15 |
rtg | go for it then. we have time to find regressions. | 19:15 |
apw | thanks all, i call that concensus | 19:15 |
ch05en | Hi, I've got a repeatable bug in the UDF filesystem that enables me to crash my box at will | 19:49 |
ch05en | 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 |
laga | ch05en: report a bug and mark it as a security vulnerability | 19:49 |
ch05en | ok | 19:49 |
laga | i'd say ;) | 19:50 |
EagleScreen | any plan to move to 2.6.29 for Jaunty? | 20:23 |
rtg | no plans | 20:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!