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