| EmigrantMTChris | I'm doing a kernel bisect to help narrow down where a bug in the kernel was introduced, and have a few questions. Would this be the proper place to ask? | 04:25 |
|---|---|---|
| johanbr | EmigrantMTChris: Yes, but now is probably not the best time of day for getting an answer. | 04:32 |
| EmigrantMTChris | Thanks, I'll ask again tomorrow. | 04:33 |
| === alex_jon1 is now known as alex_joni | ||
| elmargol | Ever tried to run intrepid on a hardy kernel? :/ I don't know anything else to do :( | 09:38 |
| elmargol | I'm frustrated :( | 09:39 |
| === abogani changed the topic of #ubuntu-kernel to: "Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Moved to 2.6.27 kernel for Intrepid/8.10. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.27-7.10 based on 2.6.27 final" | ||
| Ng | elmargol: I was running intrepid on a hardy kernel for a while, seemed to mostly work | 09:43 |
| elmargol | on the nvidia forums they suggest idle=poll as a boot parameter? what exactly does this? | 10:03 |
| elmargol | on a quick google search i could not find any informations | 10:03 |
| elmargol | kde4 and the vanilla 177.80 is totally broken :( | 10:41 |
| mdz | mjg59: there's a quote from you in bug 256887 which says we ought to be able to use the default hotkey mask in thinkpad_acpi, but testing (bug 222796) indicates that using the default breaks the volume and brightness keys for several models | 10:58 |
| mdz | mjg59: I'm considering whether we need to go back to 0xffffff for now | 10:58 |
| === asac_ is now known as asac | ||
| mjg59 | mdz: Breaks in terms of what behaviour? It's certainly possible. | 11:01 |
| mdz | mjg59: breaks in that no ACPI events are generated for those keys | 11:04 |
| mdz | mjg59: they still work (in hardware), but we don't get any notification of the change to userspace | 11:04 |
| mdz | changing the mask back to the old default of 0xffffff gets them working fine | 11:05 |
| mjg59 | Ah, right. Upstream doesn't like the keys that have direct effects in hardware sending events | 11:06 |
| mjg59 | So yeah, you might need a broader mask for that case | 11:06 |
| mdz | mjg59: given how close we are to release, I'm inclined to just revert it to the old default rather than fish around trying to figure out which bits we need. do you see any practical problem with that? | 11:07 |
| mjg59 | Not really, no | 11:09 |
| ivoks | are you guys talking about acpi keys? | 11:09 |
| ivoks | hot keys | 11:10 |
| mdz | ivoks: yes | 11:10 |
| ivoks | mdz: fwiw, toshiba laptops are really broken atm :/ | 11:11 |
| mdz | ivoks: that isn't worth much on its own; can you point to a bug report? | 11:12 |
| ivoks | give me a second... | 11:12 |
| ivoks | bug 261318 | 11:13 |
| mdz | ivoks: thanks | 11:15 |
| ivoks | i've tried creating a fdi file for hal, but that failed since i don't know hal that much :/ | 11:18 |
| mdz | the thinkpad_acpi commit which adds the warning says: | 11:19 |
| mdz | 3. Attempts to set hotkey mask to 0xffffff, which is almost never the | 11:19 |
| mdz | correct way to set up volume and brightness event reporting (and with | 11:19 |
| mdz | the current state-of-the-art, it is known to never be right way to do | 11:19 |
| mdz | it). | 11:19 |
| mdz | unhelpfully, it doesn't explain what *is* the correct way to set up volume and brightness event reporting | 11:20 |
| mdz | I don't know of another way to get at this data | 11:20 |
| crevette | hello | 11:27 |
| crevette | I've a problem with my webcam, since few weeks ago | 11:27 |
| crevette | problem with webcam should be reported against kernel ? | 11:28 |
| mdz | mjg59: the old code checked which X driver was in use (intel|ati|radeon) and only changed the mask for those three. do you know why? the changelog doesn't say, and I don't see why nvidia-based thinkpads wouldn't need this | 11:28 |
| crevette | hey mjg59 | 11:28 |
| mjg59 | At that point only those drivers supported xrandr1.2 | 11:28 |
| mdz | mjg59: ok, so it's obsolete and I'll drop it. thanks. | 11:29 |
| crevette | it seems the pwc driver reports it can works in v4l2 but is this mode the output is just a plain green color | 11:29 |
| crevette | it used to works fine 2 weeks ago | 11:30 |
| mdz | afaik, thinkpads only ship with intel, ati and nvidia, and all three of those support xrandr 1.2 | 11:30 |
| crevette | but I don't know it used v4l or v4l2 | 11:30 |
| mjg59 | crevette: Reporting v4l2 is probably correct. Something's just broken in the driver. | 11:30 |
| mjg59 | mdz: Only newer nvidia, and only if you're using nv | 11:30 |
| mdz | mjg59: we don't write that into xorg.conf anymore, so only the X server knows which driver it will use | 11:31 |
| mjg59 | Yup | 11:32 |
| mdz | mjg59: all thinkpad-keys seems to do is generate an input event. what harm would that do if the driver doesn't support xrandr 1.2? | 11:36 |
| mjg59 | It's not thinkpad-keys | 11:36 |
| mjg59 | It's whether the hotkey generates the BIOS event or an input event | 11:36 |
| mdz | mjg59: so if the key is included in the mask, it generates an acpi event. if it isn't, what happens in that case? the documentation says "the firmware will handle it", but in this case, we're only asking for notification | 11:45 |
| mdz | will masking out the brightness keys on some models prevent the hardware from adjusting the brightness? | 11:46 |
| mdz | (it doesn't on any hardware reported in the bug) | 11:50 |
| mjg59 | mdz: For video switch, you're not just asking for notification | 11:54 |
| mdz | mjg59: ok, I understand. I'm happy to let the driver decide what to do for the video switch key. the problem I'm trying to address is the regression in getting events for volume and brightness. | 11:57 |
| === rikai_ is now known as rikai | ||
| mjg59 | Yeah. In that case, setting the wider mask should be fine | 11:59 |
| mdz | mjg59: the old code was: "if intel|ati|radeon driver, set mask to 0xffffff". the new code would be: "set mask to (recommended_mask) | (bitmask for volume and brightness keys). sound ok? | 12:01 |
| mjg59 | Yeah | 12:03 |
| mdz | thank you | 12:05 |
| crevette | mjg59: I can't find a package v4l2 is it libv4l-0? | 12:14 |
| mjg59 | crevette: v4l2 is a kernel API | 12:15 |
| mjg59 | It specifies how userspace communicates with the camera | 12:15 |
| crevette | a, /me is a total newbie in video thingy | 12:15 |
| crevette | mjg59: okay so I open the bug against the kernel | 12:15 |
| Kano | hi | 12:55 |
| Kano | interested in a simple patch for one c6600 (compal jhl90) webcam? | 12:56 |
| Kano | just id addon to uvcvideo | 12:56 |
| Kano | hi rtg | 13:04 |
| rtg | Kano: hi | 13:05 |
| Kano | rtg: i have got a patch for uvcvideo and compal jhl90 barebone based systems | 13:06 |
| Kano | just made it, as simple as for the akoya | 13:06 |
| rtg | Kano: send it to kernel-team <kernel-team@lists.ubuntu.com> | 13:07 |
| Kano | no time,but i uploaded it | 13:08 |
| Kano | http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-uvcvideo-jhl90.patch | 13:08 |
| Kano | straight forward | 13:08 |
| Kano | just compied last section and added id, thats all | 13:10 |
| Kano | bbl | 13:10 |
| mdz | mjg59: if you have a moment to eyeball http://launchpadlibrarian.net/18497499/hotkey-setup-222796.diff that would be appreciated | 13:13 |
| mjg59 | mdz: Looks good | 13:36 |
| mdz | mjg59: thank you | 13:36 |
| mdz | it gets things working again on my T42, doesn't break anything on the T61 | 13:37 |
| mdz | and I've asked a bunch of folks to test | 13:38 |
| === mdz_ is now known as mdz | ||
| Ng | did something relating to USB autosuspending change in the last couple of intrepid kernels? | 13:47 |
| rtg | Ng: something broke? | 13:48 |
| Ng | rtg: sort of the opposite - I was playing around with setting the /sys/devices/pciblah/usbfoo/power/level to "auto" a week or so ago to stop my laptop's fingerprint scanner and webcam consuming power, and now they seem to come up set to "auto" all the time | 13:49 |
| Ng | I'm pretty sure that stuff shouldn't be persistent ;) | 13:49 |
| Ng | (also I'm fairly sure the fingerprint scanner is actually active, because it's warm and after my playing around it would come up cold) | 13:50 |
| rtg | Ng: CONFIG_USB_PERSIST is no longer an option in Intrepid. hmm. | 13:51 |
| Ng | yeah I couldn't see anything having changed in the /boot/config- files, nor anything relevant in the changelog | 13:52 |
| tseliot | rtg: did my patch solve your problem with nvidia? | 13:53 |
| rtg | Ng: we need an rf-kill switch for webcam and finger print sensor. | 13:53 |
| rtg | tseliot: I still had library conflicts, so I ended up installing Intrepid from scratch. I'm pretty well setup for it anyways since I always have /home on a separate partition. | 13:54 |
| rtg | Thanks for the response, though. | 13:54 |
| tseliot | no problem | 13:54 |
| Ng | rtg: that would certainly be nice. This is hardly an important problem, I'm just a bit confused why it seems to have changed | 13:54 |
| rtg | tseliot: the twinview setup works well. | 13:54 |
| tseliot | good :-) | 13:55 |
| rtg | tseliot: will you have time to explore the issues regarding nvidia-glx-177 under Hardy? | 13:55 |
| tseliot | rtg: yes, sure | 13:56 |
| Ng | oh, I seem to be looking in the wrong place is all, I'm looking in /sys/devices/pci0000:00/*/*/power/level and that's just finding the USB hub devices | 13:57 |
| Ng | in other news, I'm seeing http://picasaweb.google.co.uk/cmsjtenshu/Misc#5256616902573945746 occasionally on boot. Seems to be too early for X to be the culprit, and it causes a total kernel wedge (I had it once when not using usplash and the console was similarly corrupted, no sign of an OOPS) | 13:57 |
| Ng | tjaalton has seen it too I believe | 13:57 |
| rtg | Ng: BenC is supposed to be working on the uvesafb stuff | 13:58 |
| rtg | Ng: frannkly, I'd like to see a short enough boot time that we can do away with usplash. | 13:59 |
| Ng | rtg: definitely, but this seems to happen with or without that, and it's part way through the boot sequence and not obviously reprodicble, afaics | 13:59 |
| Ng | (and fwiw, I don't have v86d installed) | 13:59 |
| tjaalton | we should replace usplash with plymouth for jaunty | 14:00 |
| rtg | Ng: that was a usplash screen in the URL you referenced, isn't it? | 14:00 |
| AnAnt | Hello, is there any info that I should add to bug 281451 ? | 14:00 |
| persia | Good day. Anyone bored and feel like reviewing the current state of the -rt patches for intrepid? | 14:00 |
| Ng | rtg: yeah, but I've had what seems to be the same crash on one boot where I'd disabled usplash. | 14:00 |
| rtg | Ng: if you could catch one with quiet disabled , that might be helpful. My wedges have only appeared with usplash | 14:01 |
| Ng | tjaalton: or we should boot quickly enough not to need either :D | 14:01 |
| tjaalton | Ng: heh, let's be realistic here ;) | 14:02 |
| Ng | rtg: I'm moderately sure the one I saw was with quiet disabled (I generally either boot usplash or remove "quiet splash") and there was no oops, but the screen was pretty garbled | 14:02 |
| Ng | I'll at least pay more attention to where it happens | 14:02 |
| Ng | tjaalton: ;) | 14:02 |
| rtg | persia: where are you hiding them? | 14:03 |
| persia | rtg, They're applied by quilt at build-time from http://ppa.launchpad.net/abogani/ubuntu/pool/main/l/linux-rt/linux-rt_2.6.27-2.4.dsc | 14:04 |
| persia | abogani, Has been working on them : I'm only interested because of the impending kernel freeze, and wanting to make sure that it doesn't get missed. | 14:04 |
| rtg | persia: his package isn't really affected by the freeze, is it? In fact, the freeze is a good thing from his perspective. | 14:05 |
| persia | Actually, yes, it's affected by the freeze. It's a kernel freeze. That's all the kernels. | 14:05 |
| rtg | persia: I thought it was a universe package ? | 14:07 |
| persia | rtg, It is, but also a kernel. | 14:08 |
| persia | (so it has to follow both sets of rules) | 14:08 |
| rtg | persia: his quilt set doesn't apply. | 14:10 |
| persia | RIght. It did on the 10th. I suspect it needs a refresh. I'll go poke him. Thanks. | 14:10 |
| rtg | persia: it fails in some recent ACPI changes. | 14:10 |
| * persia will test to make sure it works before asking for review next time | 14:11 | |
| mdz | Ng: are you using VESA (vga=) or the default svgalib stuff? | 14:12 |
| rtg | persia: its a hard one to review anyway since there is a zillion patches. mostly one can only test if it builds and runs. | 14:12 |
| Ng | mdz: I've not consciously made any changes to the console screenmode, so there's no vga= on my kernel commandline | 14:12 |
| persia | rtg, The Studio folk did a bit of build&run testing, and it was looking pretty good (although clearly it now fails to build). | 14:13 |
| mdz | Ng: I agree with rtg, try it without quiet and see if it always hangs at the same spot in the boot process | 14:13 |
| persia | Do you guys want to look at anything more closely before it gets uploaded? I just expect that there will be a number of bugs against "linux" that are -rt specific, and would prefer it didn't have anything too insane in it. | 14:14 |
| mdz | Ng: if you can, track it down from there. if not, then try removing splash and see if it's still reproducible (and if you can get a panic) | 14:14 |
| rtg | persia: once its working, I'll build it and run it on a laptop, smoke test it at least. | 14:14 |
| Ng | mdz: will do. As I said, I'm pretty sure I've had it once without "quiet splash" and there was no kernel output, but I'll try and provoke it later | 14:14 |
| Ng | it seems kinda random :/ | 14:15 |
| mdz | Ng: if you and tjaalton are experiencing the same problem, that's certainly enough to open a bug | 14:15 |
| persia | rtg, OK. I'll come back when I've confirmed it's working again. | 14:15 |
| mdz | Ng: (use "ubuntu-bug linux" to get your hardware info automatically attached) | 14:15 |
| Ng | mdz: will do | 14:15 |
| rtg | Ng: is it always the same peripheral set? network cable connected? that kind of stuff. | 14:15 |
| Ng | rtg: hmm, I've had it both with and without network cable, but it occurs to me that I may only have seen it while on battery | 14:17 |
| rtg | Ng: good. its likely not random at the point that its wedging. | 14:18 |
| Ng | might be bug 263782 but the comments there seem to cover more than one actual bug | 14:20 |
| AnAnt | Hello, is there any info that I should add to bug 281451 ? | 14:36 |
| AnAnt | Launchpad bug 281451 in linux "uvesafb does not support 1280x800 resolution for NVIDIA graphics adapters" [Undecided,New] https://launchpad.net/bugs/281451 | 14:36 |
| Ng | rtg: ironically X just crashed, so I rebooted and disabled "quiet splash" and the crash happened and garbled the console. before I could get a camera on it my laptop switched off and then back on again (some kind of watchdog?) | 14:37 |
| Ng | it seemed like it was just printing something about VESA, but I don't see that in any normal boot logs | 14:38 |
| rtg | Ng: how bizarre. Maybe the BIOS sets a ACPI timer in case the boot process fails. | 14:38 |
| Ng | I did wonder if it was linux's reboot-on-panic stuff, but a) I think that defaults to 30seconds, b) I don't think it would look like a power cycle | 14:40 |
| rtg | Ng: thats why I think its a BIOS thing. perhaps it triple faulted. | 14:40 |
| Ng | I'll do some reboot loops tonight until I trigger it again and try and figure out from approximate timing, where it's at | 14:41 |
| rtg | cking: whats your experience when testing the triple fault method of rebooting? Does it appear like a power cycle? | 14:41 |
| cking | cking: it's a good way of resetting the processor - I suppose it's the nearest we have to power cycling the processor | 14:43 |
| cking | ^rtg^ | 14:43 |
| cking | oops | 14:43 |
| rtg | cking: I understand that, but I was asking if it looks like a power cycle or just a warm boot. | 14:43 |
| cking | rtg: I am not 100% sure - http://en.wikipedia.org/wiki/Triple_fault describes it as best as I could find. I would make sure that the magic number that needs to be set in memory before issuing it to indicate the kind of warm/cold reboot method used by the BIOS on reboot | 14:46 |
| cking | rtg: write a zero to location 0x472 for a cold reboot | 14:47 |
| cking | then issue a triple fault | 14:48 |
| Ng | well, I filed bug 282700 rather than assume it's 263782 | 14:48 |
| rtg | cking: dude, you're going way to deep. I just wanted to know if it _looks_ like a power cycle. you know, all the blinky lights go off, then back on. | 14:49 |
| cking | rtg: not sure - I didn't look at the blinky lights - superficially it looks like a power cycle - like a normal BIOS or keyboard reboot to me | 14:50 |
| cking | As vulcan death grips go it seems as good as the other methods I tested | 14:52 |
| rtg | :) | 14:52 |
| Ng | (fwiw I described it as looking like a powercycle because literally every LED on the laptop, including the one in its power button) went off and then all flashed on, as if it had been power cycled) | 14:52 |
| Ng | but that's the less important aspect of this, why it's crashing in the first place is more important ;) | 14:53 |
| rtg | Ng: actually, how its crashing is of interest, but its often not clear why until you know the cause. | 14:53 |
| rtg | catch-22 | 14:54 |
| Ng | fair enough :) | 14:54 |
| cking | rtg: A reset could occur by writing 0x6 to port 0xcf9 (an Intel PCI chip reset) - causing this style of reset too. | 14:57 |
| abogani | persia, rtg : I just uploaded a synced version of the rt patchset on my PPA. | 16:33 |
| BenC | rtg, cking, amitk: on holiday today (rtg, shouldn't you be too?), but have lrm in the works to be uploaded before COB | 18:12 |
| rtg | BenC: I should be on holiday, but there are lots of things to do. | 18:12 |
| rtg | BenC: lrm to fix firmware files issues? | 18:13 |
| BenC | rtg: firmware udeb, copyright file | 18:16 |
| BenC | most likely uvesafb will be reverted to vesafb...there's no way for me to reproduce the corruption | 18:17 |
| rtg | BenC: uvesafb seems to be causing widespread problems. | 18:17 |
| === thegodfather is now known as fabbione | ||
| === emma_ is now known as emma | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!