| bizhan | Hi All, question on msleep within kernel driver, I have a multi-thread process which one of the threads call an ioctl to a driver, inside this driver I have placed msleep() to defer time for the calling thread but it seems it puts the entire process into sleep, does anyone have any idea? | 00:46 |
|---|---|---|
| mjg59 | bizhan: What are you trying to do? | 00:59 |
| mjg59 | msleep() will block the process, yes | 00:59 |
| mjg59 | If you want to let the process continue then you need to use a workqueue or something | 00:59 |
| mjg59 | Schedule some work on it and then return | 00:59 |
| === asac_ is now known as asac | ||
| Kano | hi rtg , did you look at the uvcvideo patch? | 13:16 |
| rtg | Kano: you mean the patch that you had no time to send to the kernel team mailing list? nope, I had no time to download it or look at it. | 13:19 |
| Kano | well had to go yesterday | 13:19 |
| Kano | it is only very small, just take a look | 13:19 |
| Kano | http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-uvcvideo-jhl90.patch | 13:20 |
| Kano | but really usefull | 13:21 |
| Kano | i guess there are lots of different laptops out there based on that compal base | 13:21 |
| wgrant | rtg: Hi. I was pointed to you for debugging why my Dell laptop's brightness keys appear to never send release events in Intrepid. superm1 and others also suffer from this issue. | 13:26 |
| Vuokko | hello | 13:28 |
| rtg | wgrant: is there an LP report associated with this issue? | 13:28 |
| wgrant | rtg: Bug #261721 | 13:29 |
| rtg | wgrant: so you think if it was behaving properly, the little brightness gizmo would disappear immediately after you release the brightness control key? | 13:32 |
| wgrant | rtg: No, it would stick around for a while. But I can see lots of events in xev, and turning of X key repetition fixes it. | 13:33 |
| wgrant | s/turning of/turning off/ | 13:33 |
| rtg | wgrant: how do you turn off key repetition? | 13:34 |
| wgrant | rtg: System->Preferences->Keyboard | 13:34 |
| rtg | wgrant: aren't the brightness keys ACPI events? | 13:35 |
| wgrant | rtg: Not here, AFAICT. | 13:36 |
| wgrant | I can set them for keyboard shortcut actions, for example. | 13:36 |
| rtg | wgrant: huh, I'm not seeing the issue on my Dell laptop. What happens if you make the repeat interval longer? | 13:37 |
| wgrant | rtg: I believe that setting's broken at the moment... | 13:37 |
| wgrant | rtg: How old? Mine's an Inspiron 630m from early 2006. | 13:37 |
| rtg | wgrant: XPS M1710, maybe 18 months old? | 13:38 |
| wgrant | Hmm. | 13:38 |
| wgrant | rtg: Does xev say anything about the keys? | 13:38 |
| rtg | wgrant: I'm only getting one event per touch. | 13:40 |
| Vuokko | I have Fujitsu loox netbook and I was wondering if Ubuntu could put patch from http://panic.cs-bristol.org.uk/~jules/fujitsu-u810-debian-install-notes.html to enable keyboard lights. Am I asking something impossible? | 13:41 |
| rtg | Vuokko: email your path with an explanation of what it does to kernel-team@lists.ubuntu.com | 13:42 |
| rtg | wgrant: ok, I sometimes see 4 events with a single button press. | 13:42 |
| wgrant | rtg: When I have no g-p-m running to catch the events, and have repeating off, I just see http://paste.ubuntu.com/57424/. No corresponding release. | 13:44 |
| wgrant | Hmmm | 13:47 |
| wgrant | I note that the keys will only work once, unless I VT switch. | 13:47 |
| rtg | wgrant: well, see if you can find other folks with the same problem 'cause it isn't going to be something I'll get to for the next few weeks. | 13:48 |
| rtg | release is approaching, and there are some pressing issues. | 13:49 |
| rtg | need coffee... | 13:49 |
| wgrant | And huh... subsequent keypresses appear once the VT is switched back. | 13:49 |
| wgrant | But only one for each key ever appears. | 13:51 |
| ctshh | hi everyone... is there a known way of making a kernel only boot on a processor with a specific processor number, ie. let it _not_ boot on just any given processor?hi everyone... is there a known way of making a kernel only boot on a processor with a specific processor number, ie. let it _not_ boot on just any given processor? | 14:05 |
| ctshh | oops. wtf??? sorry. | 14:05 |
| ctshh | once would have been enough i guess :) | 14:05 |
| rtg | ctshh: its likely it has to boot one the same CPU every time, but you can look for phrases like 'affinity' | 14:06 |
| rtg | s/boot one/boot on/ | 14:06 |
| ctshh | ok, my bad: i mean on a specific cpu as in "my cpu, but not yours" - as mine has another procesor number (ie processor ID!) as yours. | 14:07 |
| rtg | ctshh: haven't the foggiest | 14:09 |
| ctshh | me neither :) | 14:10 |
| ctshh | this question doesnt seem to come up too often... | 14:10 |
| rtg | BenC: are you still thinking about reverting from uvesafb ? | 14:27 |
| pgraner | rtg: any word on the screen corruption issues, mario pinged me. | 14:34 |
| rtg | pgraner: hence, my question to BenC | 14:35 |
| pgraner | rtg: I had it happen to me on an Intel graphics chip last night, then it went away and hasn't happened yet | 14:36 |
| BenC | pitti said his got fixed recently, although I have no idea how | 14:37 |
| BenC | rtg, pgraner: but yeah, after I do this linux-firmware split from lrm, I'll do a new kernel upload reverting back to vesafb | 14:38 |
| pgraner | BenC: can you run that one down in time for the meeting? | 14:38 |
| BenC | pgraner: and re: HPA, it is not new to intrepid | 14:39 |
| BenC | pgraner: run it down? | 14:39 |
| pgraner | BenC: what pitti did | 14:39 |
| BenC | pgraner: he assumed I fixed it, so I am chalking it up to a fluke | 14:40 |
| pgraner | BenC: on HPA, the issue is that in Hardy systems with HPA "just worked", now in intrepid they are crapping out on boxes with a HPA disk | 14:40 |
| pgraner | BenC: we owe Mario more than "chalking it up" | 14:40 |
| rtg | BenC: What's LRM -7.10 ? Isn't that the firmware split? | 14:40 |
| BenC | pgraner: Uh, no, I mean I am ignoring the fact that pitti says it is fixed for him because there's no reason it should be | 14:41 |
| BenC | pgraner: I am reverting to vesafb, and that's about the best answer we can give | 14:41 |
| BenC | rtg: No, that was just udeb's and copyright | 14:42 |
| pgraner | BenC: Ok, understand, do we have root cause other than we are just reverting? | 14:42 |
| BenC | rtg: cjwatson wants firmware split out, and have an upgrade path for people that didn't have lrm-common | 14:42 |
| rtg | BenC: oh, I didn't look into the diff. | 14:42 |
| BenC | pgraner: root cause is that uvesafb is a little buggy | 14:42 |
| pgraner | BenC: ack | 14:42 |
| BenC | pgraner: vesafb will at least put us back to what worked in hardy | 14:43 |
| rtg | pgraner: maybe this is the last release for usplash. we can spend all winter working on the 5 second boot. | 14:43 |
| pgraner | rtg: thats the plan... | 14:43 |
| * BenC would be amazed if we could get gdm up in 5 seconds | 14:44 | |
| pgraner | BenC: you didn't see the X changes keithp is doing and some of the other bits to get us closer. | 14:45 |
| rtg | BenC: well, its simply a matter of taking unrealistic short cuts. | 14:45 |
| pgraner | rtg: s/short cuts/tradeoffs/ | 14:45 |
| BenC | does it involve kernelmodesetting? | 14:45 |
| pgraner | BenC: nope, most of it was ripping cpp out of X at start up | 14:46 |
| BenC | cpp? | 14:47 |
| * BenC hopes that isn't /usr/bin/cpp | 14:47 | |
| pgraner | BenC: the C preprocessor | 14:47 |
| mjg59 | xkb file compilation | 14:47 |
| BenC | wow, I never knew that sort of crap was taking place at X startup | 14:47 |
| mjg59 | Turns out that caching the compiled keymap is some kind of performance win | 14:47 |
| BenC | who would have thought | 14:48 |
| sebner | hi, mighty kernel guys. already plans for jaunty and ext4? | 14:55 |
| * BenC needs more coffee | 14:56 | |
| rtg | sebner: the next kernel upload will have EXT4_DEV enabled. | 14:58 |
| Kano | ext4 tools in repo? | 14:58 |
| sebner | rtg: what do you mean with "next kernel upload". I'm curious because jaunty will have at least 2.6.28 (I suppose) and in 2.6.28 is ext4 now marked as stable ;) | 14:59 |
| rtg | according to keybuk we have the latest from Ted. | 14:59 |
| rtg | sebner: Intrepid is 2.6.27, and therefore has the development version of ext4 | 15:00 |
| sebner | rtg: therefor I was asking about "Jaunty" and ext4 ;) | 15:00 |
| Kano | did somebody else found gspca problematic in 2.6.27? | 15:00 |
| rtg | sebner: you'll have to wait until after the December UDS for us to make that decision. | 15:01 |
| Kano | it seems it can even stop booting - at least the cam is not working... | 15:01 |
| sebner | rtg: any vision about the chances? | 15:01 |
| BenC | pgraner: seems in intrepid, we moved to making HPA honored by default, which was due to pressure from upstream (alan cox, among others) | 15:02 |
| rtg | sebner: about it being the default? the likelyhood is high. | 15:02 |
| BenC | pgraner: way back in edgy we ignored the host protected area | 15:02 |
| sebner | rtg: cool. thx for the info :) | 15:03 |
| BenC | pgraner: which was to keep consistency across the move from ide to pata | 15:03 |
| BenC | pgraner: ide has always ignored hpa by default | 15:03 |
| pgraner | BenC: so do something need to happen in the installer so that we fence that portion off to avoid crashing? | 15:03 |
| rtg | sebner: besides, Jaunty is most likely going to be a 2.6.29 or perhaps even .30 kernel. ext4 will have matured some by then. | 15:04 |
| sebner | rtg: .30?? 27 is just out and 1 kernel version every 2,5 months .. hard :) | 15:04 |
| pgraner | Kano: the gspca bits userspace patches are being applied and seem to be working for me. | 15:05 |
| Kano | pgraner: for skype? | 15:05 |
| Kano | and what about boot problems with webcam? | 15:05 |
| pgraner | Kano: we are packaging skype for Intrepid and it will have the fixes either patching or the LD_PRELOAD method before GA | 15:06 |
| BenC | pgraner: it would seem so | 15:06 |
| pgraner | Kano: other than you I've seen no other boot probs with the web cam | 15:06 |
| BenC | pgraner: the kernel is DTRT | 15:06 |
| Kano | pgraner: it was a laptop, could not boot when it was connected. | 15:07 |
| pgraner | BenC: ack, we need to get with the platform guys to get this sorted | 15:07 |
| BenC | pgraner: On it... | 15:07 |
| Ng | rtg: re the bug with hangs and visual corruption on boot, I think it's happening very shortly after intel_agp loads (dunno if you saw the comment on th ebug, but i added a couple of pictures of it happening without usplash | 16:40 |
| Ng | which seems like it could be a prime candidate, I guess | 16:41 |
| rtg | Ng: we were just having a conversation about reverting to vesafb as the preferred frame buffer driver. hopefully the usplash corruption issue will be moot. | 16:42 |
| Ng | I don't think I'm using uvesafb though, I have log messages suggesting it fails | 16:43 |
| Ng | but I've never understood console video modes very well, I don't use them enough to care ;) | 16:44 |
| rtg | Ng: or do I. | 16:44 |
| rtg | s/or/nor/ | 16:44 |
| Ng | [ 2.833626] uvesafb: vbe_init() failed with -22 | 16:44 |
| Ng | [ 2.833715] uvesafb: probe of uvesafb.0 failed with error -22 | 16:44 |
| Ng | that's the last thing uvesafb has to say for itself | 16:44 |
| rtg | Ng: what does get loaded? vesafb16 ? | 16:45 |
| Ng | hmm, maybe I am using uvesafb then, because that's the only kernel module I have loaded which matches "vesa" | 16:45 |
| amitk | Ng: IIRC, that error has got to do with not having 'v86d' installed | 16:49 |
| amitk | Ng: try installing v86d to check if your problems go away | 16:50 |
| Ng | amitk: will do, although I've tried that at several points in the cycle and had things generally get worse, like X failing to start ;) | 16:51 |
| * amitk nods | 16:53 | |
| BenC | Ng: ignore it for now, we're making vesafb the default again | 17:46 |
| Ng | ok | 17:46 |
| * Ng purges v86d with fire | 17:46 | |
| Ng | I'll do some more reboot loop testing when i spy a new kernel with that change :) | 17:47 |
| rtg | Ng: x86 or x86_64? I can provide a test kern. | 17:48 |
| Ng | x86 | 17:48 |
| rtg | Ng: 10 minutes (or so) | 17:49 |
| Ng | groovy :) | 17:50 |
| rtg | Ng: http://people.ubuntu.com/~rtg/vesafb for test kernels | 18:44 |
| Ng | rtg: ta | 18:45 |
| persia | I thought I was here. Wonder how it fell off the list. | 18:56 |
| BenC | persia: It will have to be done separately | 18:57 |
| BenC | we can't have lrm build-dep on something we aren't directly supporting | 18:57 |
| BenC | persia: I'm curious if fglrx and nvidia dkms build ok with it | 18:58 |
| persia | BenC, Rather, to have l-r-m generate l-r-m source so l-r-m-rt can build-dep on it. That's what abogani wanted. If that's infeasible, the source can be copied. | 18:58 |
| BenC | persia: just copy the source...there's only 4 modules there (and firmware will get moved to another package and be arch/kernel indep) | 18:58 |
| persia | I'll ask to have the dkms stuff tested. I know at least nvidia isn't rt-safe, and crashes. | 18:58 |
| BenC | well, firmware is already arch/kernel indep | 18:58 |
| persia | OK, so the linux-firmware (or whatever) package should be safe to just have linux-meta-rt depend upon? | 18:59 |
| BenC | persia: right | 19:29 |
| persia | OK. Cool. Thanks. | 19:31 |
| === jws141 is now known as dashua | ||
| === jws141 is now known as dashua | ||
| jdong | so what's up with CONFIG_EXT4DEV_FS? would I still be an insane idiot to attempt ext3->ext4dev? | 22:52 |
| jdong | (yeah I know, I am one ext4 or not) | 22:52 |
| Vuokko | what's the fuzz about ext4? isn't ext3 good enough? | 22:54 |
| laga_ | no. obviously not | 22:55 |
| Vuokko | nothing is ever good enough :( | 22:57 |
| laga_ | 640k... | 22:59 |
| philsf | is there anything (testing) I can do to help fix bug #55567 in time for intrepid? It includes a hardware driver inclusion. | 23:40 |
| philsf | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/55567 | 23:40 |
| Ng | rtg: no good I'm afraid, I got the same corruption/crash on the 16th boot | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!