[00:46] <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:59] <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
[13:16] <Kano> hi rtg , did you look at the uvcvideo patch?
[13:19] <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:20] <Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-uvcvideo-jhl90.patch
[13:21] <Kano> but really usefull
[13:21] <Kano> i guess there are lots of different laptops out there based on that compal base
[13:26] <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:28] <Vuokko> hello
[13:28] <rtg> wgrant: is there an LP report associated with this issue?
[13:29] <wgrant> rtg: Bug #261721
[13:32] <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:33] <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:34] <rtg> wgrant: how do you turn off key repetition?
[13:34] <wgrant> rtg: System->Preferences->Keyboard
[13:35] <rtg> wgrant: aren't the brightness keys ACPI events?
[13:36] <wgrant> rtg: Not here, AFAICT.
[13:36] <wgrant> I can set them for keyboard shortcut actions, for example.
[13:37] <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:38] <rtg> wgrant: XPS M1710, maybe 18 months old?
[13:38] <wgrant> Hmm.
[13:38] <wgrant> rtg: Does xev say anything about the keys?
[13:40] <rtg> wgrant: I'm only getting one event per touch.
[13:41] <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:42] <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:44] <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:47] <wgrant> Hmmm
[13:47] <wgrant> I note that the keys will only work once, unless I VT switch.
[13:48] <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:49] <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:51] <wgrant> But only one for each key ever appears.
[14:05] <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:06] <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:07] <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:09] <rtg> ctshh: haven't the foggiest
[14:10] <ctshh> me neither :)
[14:10] <ctshh> this question doesnt seem to come up too often...
[14:27] <rtg> BenC: are you still thinking about reverting from uvesafb ?
[14:34] <pgraner> rtg: any word on the screen corruption issues, mario pinged me.
[14:35] <rtg> pgraner: hence, my question to BenC
[14:36] <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:37] <BenC> pitti said his got fixed recently, although I have no idea how
[14:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44]  * BenC would be amazed if we could get gdm up in 5 seconds
[14:45] <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:46] <pgraner> BenC: nope, most of it was ripping cpp out of X at start up
[14:47] <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:48] <BenC> who would have thought
[14:55] <sebner> hi, mighty kernel guys. already plans for jaunty and ext4?
[14:56]  * BenC needs more coffee
[14:58] <rtg> sebner: the next kernel upload will have EXT4_DEV enabled.
[14:58] <Kano> ext4 tools in repo?
[14:59] <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.
[15:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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...
[16:40] <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:41] <Ng> which seems like it could be a prime candidate, I guess
[16:42] <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:43] <Ng> I don't think I'm using uvesafb though, I have log messages suggesting it fails
[16:44] <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:45] <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:49] <amitk> Ng: IIRC, that error has got to do with not having 'v86d' installed
[16:50] <amitk> Ng: try installing v86d to check if your problems go away
[16:51] <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:53]  * amitk nods
[17:46] <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:47] <Ng> I'll do some more reboot loop testing when i spy a new kernel with that change :)
[17:48] <rtg> Ng: x86 or x86_64? I can provide a test kern.
[17:48] <Ng> x86
[17:49] <rtg> Ng: 10 minutes (or so)
[17:50] <Ng> groovy :)
[18:44] <rtg> Ng: http://people.ubuntu.com/~rtg/vesafb for test kernels
[18:45] <Ng> rtg: ta
[18:56] <persia> I thought I was here.  Wonder how it fell off the list.
[18:57] <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:58] <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:59] <persia> OK, so the linux-firmware (or whatever) package should be safe to just have linux-meta-rt depend upon?
[19:29] <BenC> persia: right
[19:31] <persia> OK.  Cool.  Thanks.
[22:52] <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:54] <Vuokko> what's the fuzz about ext4? isn't ext3 good enough?
[22:55] <laga_> no. obviously not
[22:57] <Vuokko> nothing is ever good enough :(
[22:59] <laga_> 640k...
[23:40] <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:43] <Ng> rtg: no good I'm afraid, I got the same corruption/crash on the 16th boot