| dyek | Hi! I added a bunch of CONFIG_* that I thought was necessary for Xen DomU support in Ubuntu linux-image kernel package in debian.master/config/i386/config.flavour.generic file. After "debian/rules updateconfigs" and created the .deb package, much of those added CONFIG_* disappeared from the package's config-* file. Are they disappearing because I added it to the wrong flavor config file? Or are they simply not supported by the kernel source from | 08:32 |
|---|---|---|
| dyek | the package? I'm getting "Error: (2, 'Invalid kernel',..." when I launch the kernel as DomU. It seems to me that it is hopeless to try to recompile the Ubuntu kernel package hoping that it will fix the Xen DomU support. Does that sound correct? | 08:32 |
| dyek | I suspect that these CONFIG_* (CONFIG_XEN, CONFIG_XEN_BLKDEV_FRONTEND, CONFIG_XEN_NETDEV_FRONTEND, CONFIG_XEN_KBDDEV_FRONTEND, CONFIG_HVC_XEN, CONFIG_VIRTIO_CONSOLE, CONFIG_XEN_FBDEV_FRONTEND, CONFIG_XENFS) are likely needed to enable Xen DomU support. Any comment on that? I can't seem to effectively add these CONFIG_* though. They were reset (disappeared) after creating the kernel .deb package. | 08:35 |
| dyek | I tried that CONFIG_M586TSC and CONFIG_M686 isn't the real issue -- discussed in https://lists.ubuntu.com/archives/kernel-team/2010-February/008716.html. | 08:36 |
| kengyu | dyek, guess the missing CONFIG_* are in debian.master/config/config.common.ubuntu | 08:38 |
| dyek | kengyu: Thanks! Glad to know that. That makes it sounds hopeful again. So, I need to figure out why then those CONFIG don't appear in the final config-* file in the linux-image*.deb package. I have been trying to add them into the generic flavor, but I guess there are build scripts that would insist that they appear only in some flavor? | 08:45 |
| dyek | Even the generic-pae flavor doesn't have those Xen CONFIG_* in the resulting config-* file. | 08:47 |
| apw | dyek, if you added them to -generic only then they would not be set on generic-pae, and as i recall XEN needs M586TSC at least turned on, so xen cannot be enabled in the current generic kernel configuration, those items are incompatible with the CPU level. if you add them to the config.common.ubuntu, and then run fakeroot debian/rules updateconfigis ... do they remain enalbed? | 09:02 |
| dyek | apw: I added them to -generic, hopefully to get a custom -generic package that works as DomU kernel. It doesn't need to be in generic-pae if that works. | 09:04 |
| apw | the -generic kernels cpu selection is not high enough to allow XEN to be enabled | 09:05 |
| dyek | apw: I tried with M586TSC and also M686; they appear in the final config-* file, but the problem remains. | 09:05 |
| dyek | apw: Is there a way to change that? | 09:05 |
| apw | can you pastebin the fragment of options you are trying to set | 09:05 |
| dyek | apw: For my local package, that is. | 09:06 |
| apw | so i can see the exact options you are trying to enable | 09:06 |
| dyek | apw: But they are not in the final config-* file, or are they, in your case? | 09:07 |
| apw | dyek, without knowing exactly what you are setting i have no idea, if you pastebin the enable fragment you are adding then i can try and reproduce | 09:08 |
| dyek | apw: I added a bunch of CONFIG_, mostly listed here: CONFIG_M686, CONFIG_HAVE_INTEL_TXT, CONFIG_XEN, CONFIG_XEN_SAVE_RESTORE, CONFIG_XEN_BLKDEV_FRONTEND, CONFIG_XEN_NETDEV_FRONTEND, CONFIG_XEN_KBDDEV_FRONTEND, CONFIG_HVC_XEN, CONFIG_VIRTIO_CONSOLE, CONFIG_XEN_FBDEV_FRONTEND, CONFIG_XENFS, CONFIG_XEN_COMPAT_XENFS, CONFIG_X86_CMPXCHG64, CONFIG_X86_MINIMUM_CPU_FAMILY=5, CONFIG_X86_PAE, CONFIG_IEEE802154_FAKEHARD, CONFIG_XEN_BALLOON, CONFIG_XEN_DEV_ | 09:11 |
| dyek | EVTCHN. | 09:11 |
| dyek | I'll pastebin. | 09:12 |
| dyek | apw: Here you go: http://pastebin.ca/1841032 ; Note that I am only experimenting with these CONFIG_* hoping to get a Ubuntu kernel running as DomU kernel. I have no idea if these constitute a fix for the problem. Thanks for working on reproing it! | 09:16 |
| apw | dyek, as the -pae kernel does have xen enabled, have you tried just using that kernel? | 09:21 |
| dyek | apw: Yes, I tried. No -pae kernel worked. The latest version I tried was released on Feb. 8th, 2010. Did someone find the -pae kernel working as DomU? | 09:22 |
| apw | dyek, the fixes to enable that in lucid was only commited on the 9th feb | 09:23 |
| dyek | apw: I didn't find other newer packages. So, I ended up adding CONFIG_* and built it myself, which didn't work too... | 09:24 |
| dyek | apw: I was trying out lucid kernel for karmic, but a lot of dependencies are getting in the way. | 09:25 |
| apw | dependancies on binutils? | 09:26 |
| dyek | Yes. I tried upgrading binutils, but it didn't work for me. (vaguely...) | 09:26 |
| apw | smb, do we not expect XEN domU to work in karmic PAE kernels? | 09:26 |
| apw | dyek, the depenancy there will go away again after the freeze, iit is triggeed by an inbuilt binary which we are pulling out | 09:27 |
| smb | apw, I think we would for uploads containing the changes to the m586 option. | 09:27 |
| dyek | apw: OK! | 09:28 |
| smb | I am not sure this in now or will be in the next upload to proposed | 09:28 |
| apw | smb, yeah not sure either, may well still be pending | 09:30 |
| smb | apw, dyek Its still pending | 09:30 |
| dyek | apw, smb: However, I did make a local build off the linux-image source package after adding just CONFIG_M586TSC=y. The CONFIG was added successfully, but that didn't do the magic for me. | 09:30 |
| apw | smb, is there a pre-proposed kernel up which has it in | 09:30 |
| smb | Yes | 09:30 |
| apw | dyek, that change was made against -pae which has other otptions changed ... | 09:30 |
| smb | Should be in what is currently in the pre-proposed PPA of kernel-ppa | 09:31 |
| apw | dyek, i would recommend testing the pae kernel from the pre-proposed PPA, and see if that works | 09:31 |
| apw | thtat is expected to have Xen support enabled for domU use | 09:31 |
| dyek | Is there a link to a pre-release package that I can try? | 09:32 |
| smb | https://launchpad.net/~kernel-ppa/+archive/pre-proposed | 09:32 |
| smb | dyek, ^ | 09:32 |
| apw | smb, are we intending to keep all of the series up to date in there? | 09:33 |
| smb | apw, Yes, more or less. But usually its the latest that has the worst backlog | 09:34 |
| JFo | apw, thank you for weighing in on that vserver issue. That is precisely what I thought. :) | 09:36 |
| apw | its a humongous patch set, you might well want to close it Won't Fix | 09:37 |
| dyek | smb: Thanks! I'll give this package a try: https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+build/1525835/+files/linux-image-2.6.31-21-generic-pae_2.6.31-21.58~pre1_i386.deb | 09:37 |
| smb | dyek, Ok. Yes, that should include the change. | 09:38 |
| JFo | apw, will do | 09:38 |
| dyek | This package's config- file does look much hopeful... | 09:41 |
| dyek | apw, smb: The -pae kernel worked as DomU! I can login to VNC desktop successfully. The mouse cursor is not at the right coords., but at least, DomU is working! Thanks so much. | 10:06 |
| apw | amitk, so i see you handed some of your stuff over to cnd, which things went there | 10:10 |
| amitk | apw: the 'porting' of laptop-mode-tools script to pm-utils | 10:11 |
| amitk | everything else should be postponed | 10:11 |
| apw | amitk, is the 'investigate the ones in l-m-t' one now complete? as you were at the getting patches working and reviewed i assume so? | 10:27 |
| amitk | apw: correct | 10:31 |
| apw | amitk, but that is the one which has been pushed out to beta-2 and the 'implement' one is postponed to M | 10:32 |
| * apw looks a little confused | 10:32 | |
| apw | amitk, any idea what cnd has been asked to do there? | 10:33 |
| amitk | apw: pgraner was talking to cjwatson about the tasks. I am distracted by another phone call on Friday | 10:34 |
| amitk | apw: cnd should be fixing the 'implementation' | 10:34 |
| amitk | s/am/was | 10:35 |
| apw | ok will get with them and sort out whats really left | 10:35 |
| apw | amitk, what did we decide to do about SECCOMP on arm ? | 11:44 |
| amitk | apw: we decided to fix it, I have a patch, need to free up some time to test | 12:23 |
| apw | ok ... so when do we think we might have that? sometime after freeze i assume | 12:24 |
| amitk | apw: it didn't seem like a burning priority, so yes | 12:29 |
| apw | amitk, works for me thanks | 12:30 |
| tgardner | apw, can't parse some of this commit log, "This patch adds the kernel EXTRAVERSION to /proc/version_signature and though that also to the kernel version banner." | 12:44 |
| apw | the kernel version banner includes the same output as /proc/version_signature, its in () at the right end | 12:45 |
| apw | dmesg | grep Linux\ version | 12:45 |
| tgardner | apw, I get the patch, I just don't get your commit log line. | 12:45 |
| _ruben | s/though/through/ probably? :) | 12:45 |
| apw | ahh yeah what _ruben says | 12:45 |
| apw | text and i do not mix well | 12:46 |
| _ruben | hehe | 12:46 |
| tgardner | apw, ah, perhaps you could correct that before committing? | 12:46 |
| apw | tgardner, yeah a good plan | 12:46 |
| apw | fixed in my tree | 12:48 |
| tgardner | apw, thats, I'll uncross my eyes now :) | 12:48 |
| tgardner | thanks* | 12:48 |
| tgardner | can't damn type this morning | 12:48 |
| apw | neither can i apparently :) | 12:49 |
| cnd | amitk: if we remove the echo into /dev/dsp in ac97-powerdown, will the script stlil work right? | 13:42 |
| cnd | will the sound card power down now, or wait until the next audio bits are pushed? | 13:42 |
| amitk | cnd: it'll wait until the next audio bits is my guess, but i don't have the HW to be sure. | 13:45 |
| cnd | amitk: so why are we removing it? just cause it looks bad? | 13:45 |
| cnd | amitk: is there a thread of comments somewhere so I can figure out how some of these decisions were made? | 13:46 |
| amitk | we don't even know if the echo works, e.g. on my machine it says the device is busy | 13:46 |
| cnd | oh, ok | 13:46 |
| amitk | cnd: most of the are adaptations for the laptop-mode-tools scripts | 13:47 |
| amitk | have a look at the source of that package | 13:47 |
| cnd | amitk: so I see where you took your scripts from, but where are these comments to change the scripts coming from | 14:04 |
| amitk | cnd: what comments? | 14:04 |
| cnd | amitk: the comments you sent me in the email | 14:04 |
| cnd | the list of things you think should be changed | 14:04 |
| amitk | cnd: my own comments for the sched-mc/mt scripts | 14:05 |
| amitk | cnd: ohh, that | 14:05 |
| amitk | we reviewed them on IRC | 14:05 |
| cnd | who's "we"? | 14:05 |
| amitk | pitti and me | 14:05 |
| amitk | I | 14:06 |
| cnd | ok, so basically I should be interfacing with pitti about any issues? | 14:06 |
| amitk | cnd: what are those issues? | 14:06 |
| cnd | for example, the ac97 powerdown, I think we should still be trying to push a few bits to enable it, since that's what laptop-mode-tools does | 14:07 |
| cnd | but it pipes stderr to /dev/null, so you don't get any warnings | 14:07 |
| cnd | so I figured we'd do the same | 14:07 |
| amitk | cnd: have you tried writing to /dev/dsp on your machine? | 14:07 |
| cnd | I just did | 14:08 |
| cnd | it seemed fine, though it output a little blip | 14:08 |
| apw | cnd, echo "" >/dev/dsp works here, and comes with a click ... echo -n is silent | 14:08 |
| amitk | cnd: then leave it in there but find a way to log failures IMO | 14:09 |
| cnd | amitk: this is the comment from laptop-mode-tools: | 14:09 |
| cnd | # This can fail if the audio device is busy. | 14:09 |
| cnd | # Since this failure is non-fatal (worst case is that the timer changes | 14:09 |
| cnd | # don't get activated), we don't bother if it was successful or not | 14:09 |
| cnd | #(exec 2>/dev/null; echo 1 > /dev/dsp;) | 14:09 |
| cnd | # Better way | 14:09 |
| cnd | so I don't think we need to log anything | 14:10 |
| cnd | apw, echo -n "" > /dev/dsp gave me issues | 14:10 |
| cnd | nm | 14:10 |
| cnd | seems to work now | 14:10 |
| amitk | cnd: so the change might be enabled or not? | 14:11 |
| apw | may not work of course if it sends nothing | 14:11 |
| cnd | apw, yeah, I'm going to look into that | 14:11 |
| cnd | amitk: it should work, unless someone else is holding onto /dev/dsp, in which case they will likely take care of it anyways | 14:12 |
| amitk | cnd: ok | 14:12 |
| crimsun | wow, that's crufty | 14:15 |
| crimsun | (laptop-mode-tools) | 14:16 |
| cnd | amitk: have to done any tests to see if you can change hda power_save at runtime and have it take effect? | 14:16 |
| cnd | the driver code looks like it only takes effect on device probing | 14:17 |
| cnd | so it wouldn't have any effect unless you reloaded the driver with the new value | 14:17 |
| amitk | cnd: it does work at run-time, crimsun should be able to help with HDA power save | 14:17 |
| cnd | oh, I think I just found where it would change it at runtime | 14:17 |
| crimsun | cnd: no, you can echo 1 > /sys/class/sound/hwCfoo/reconfig | 14:17 |
| amitk | he did the patch for HDA audio | 14:18 |
| cnd | crimsun: now that I look further, I'm confused | 14:18 |
| crimsun | cnd: granted, the same caveat as with ac97; no processes can have /dev/{dsp,snd/*,seq,...} open | 14:19 |
| cnd | crimsun: so we have to echo 1 > .../power_save | 14:19 |
| cnd | then we have to echo 1 > .../reconfig? | 14:19 |
| crimsun | cnd: it depends on the driver's current config | 14:20 |
| cnd | crimsun: true, but if it had power_save disabled before, the reconfig would be necessary? | 14:20 |
| crimsun | cnd: presuming you meant power_save_controller -> N before, yes | 14:21 |
| cnd | crimsun: I'm meaning just power_save for now | 14:21 |
| cnd | crimsun: can you explain the difference between power_save and power_save_controller? | 14:22 |
| crimsun | cnd: if power_save_controller == N, then to effect changes you need to echo into reconfig | 14:22 |
| crimsun | cnd: if power_save_controller == Y, then you don't need any echo into reconfig | 14:22 |
| crimsun | cnd: sure, power_save is the idle timeout in seconds; power_save_controller affects whether the controller is reset coming out of power_save | 14:23 |
| crimsun | note that you can generally get away with not doing a reconfig, but it can be iffy | 14:23 |
| cnd | crimsun: so if power_save == 0, then the chip is never powered down right? | 14:24 |
| crimsun | cnd: correct | 14:24 |
| cnd | crimsun: ok, then my question is: how is a power_save change handled in the driver | 14:25 |
| cnd | I see power_save set for the chip in azx_max_codecs | 14:25 |
| cnd | which is called from the device probe functions | 14:25 |
| cnd | so if I change power_save through a sysctl, how does that have any effect? | 14:26 |
| cnd | crimsun: I think I see where I was getting confused | 14:30 |
| cnd | crimsun: so, if you change power_save through a sysctl, do you need to push some bits through /dev/dsp to enable the change, like is done in laptop-mode-tools? | 14:31 |
| crimsun | cnd: a reconfig will work; pushing bits through /dev/dsp should work, too | 14:33 |
| cnd | crimsun: which makes the most sense to you: echo 1 > /dev/dsp or echo 1 > .../reconfig? | 14:34 |
| crimsun | cnd: presuming nothing in userspace is still active in /dev/{dsp,snd/*,seq,...}, the former | 14:36 |
| cnd | crimsun: we can't guarantee that though, so does it change your answer? | 14:36 |
| crimsun | cnd: no | 14:36 |
| cnd | k, thanks | 14:37 |
| * BenC bids good morning to everyone | 15:08 | |
| amitk | morning BenC | 15:08 |
| smb | BenC, morning | 15:09 |
| === sconklin1 is now known as sconklin | ||
| apw | moin BenC | 15:56 |
| manjo | apw, no regression call today ? | 16:03 |
| tgardner | pgraner, I have not checked in the past two weeks, but prior to that plymouth was the culprit on nVidia. | 16:45 |
| apw | akgraner, you have 25 hangs a day i hear, is there a bug number? | 16:46 |
| pgraner | tgardner: this happens on akgraner's m1330, just random freeze mouse works ut nothing else | 16:46 |
| akgraner | apw, nope | 16:46 |
| pgraner | akgraner: ubuntu-bug linux | 16:46 |
| akgraner | apw, I try to file a bug through apport and it tells me I can't because I am not up to date grrrrr | 16:46 |
| apw | akgraner, does it tend to occur when you arn't using it activly | 16:47 |
| apw | akgraner, i know same happens to me all the time | 16:47 |
| akgraner | apw -it happens when I am using multiple applications launched by the messaging indicator/notifier (what ever you call the envelope) | 16:48 |
| apw | akgraner, one thing to try would be to try booting with i915.powersave=0 ... have heard rumors that issues still occur with other i915 chipsets, and i'd guess the m1330 would fall into that category | 16:48 |
| apw | idle here would be a few seconds at most, so you might not 'be' idle per-see | 16:49 |
| akgraner | apw, hmm I'll pay closer attention, and make some detailed notes for ya if that will help? | 16:49 |
| apw | well if its 25 times a day we should know in less than a coupld of hours if the option helps, that'd be my first test | 16:50 |
| Sarvatt | what's the right way to force firmware into the initrd? some people want to try using the blob ctxprogs firmware for nouveau instead of the runtime generated ones that could be causing issues using the ctxfw module option but its not getting packed into the initrd because the module doesn't say it needs it | 16:57 |
| pgraner | cking: are you running lucid on your HP mini? | 17:17 |
| cking | pgraner, yes, but not used it for 5+ weeks now | 17:17 |
| pgraner | cking: Check your dmesg and see if the sky2 has this: sky2 0000:02:00.0: unsupported chip type 0xff | 17:19 |
| cking | will do | 17:19 |
| pgraner | cking: if so we should kick apw.... | 17:19 |
| === amitk is now known as amitk-afk | ||
| tgardner | pgraner, just send it to Hemminger with instructions to 'plsfx" | 17:20 |
| pgraner | tgardner: it was working a few weeks ago, we regressed in one of the stable updates /methinks | 17:21 |
| tgardner | pgraner, do you have version boundaries? | 17:21 |
| * cking goes into the loft to get the machine | 17:22 | |
| pgraner | tgardner: nope, I don't use it that often, I used it to do a rsync off my server about 3 weeks ago and it worked fine. But it did work | 17:22 |
| tgardner | ok, about -15 perhaps | 17:23 |
| pgraner | tgardner: the whole snippet is: | 17:24 |
| pgraner | [ 204.826365] sky2 driver version 1.25 | 17:24 |
| pgraner | [ 204.826456] sky2 0000:02:00.0: enabling device (0000 -> 0003) | 17:24 |
| pgraner | [ 204.826482] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 | 17:24 |
| pgraner | [ 204.826516] sky2 0000:02:00.0: setting latency timer to 64 | 17:24 |
| pgraner | [ 204.826651] sky2 0000:02:00.0: unsupported chip type 0xff | 17:24 |
| pgraner | [ 204.826687] sky2 0000:02:00.0: PCI INT A disabled | 17:24 |
| pgraner | [ 204.826712] sky2: probe of 0000:02:00.0 failed with error -95 | 17:24 |
| tgardner | pgraner, lucid, right? 2.6.32-13.18 - 'sky2: Fix oops in sky2_xmit_frame() after TX timeout' was the last change | 17:25 |
| pgraner | tgardner: yep | 17:25 |
| pgraner | nice apport won't let me file a bug... "Can't connect to the crash database, please check you internet connection" | 17:27 |
| tgardner | pgraner, hmm, thats early, early init and brain dead simple. Have you checked that it didn't get turned off in the BIOS? | 17:28 |
| pgraner | tgardner: I'll look. | 17:28 |
| pgraner | tgardner: should rfkill show me all the devices in my system? bt, wifi & wired? | 17:29 |
| pgraner | i.e. rfkill list all? | 17:29 |
| tgardner | just rfkill list IIRC | 17:30 |
| pgraner | pgraner@zorak:~$ rfkill list | 17:30 |
| pgraner | 1: hci0: Bluetooth | 17:30 |
| pgraner | Soft blocked: no | 17:30 |
| pgraner | Hard blocked: no | 17:30 |
| pgraner | tgardner: I'm not seeing wifi (its working cuz I'm using the box for irc to type this) | 17:31 |
| pgraner | tgardner: and not seeing wired | 17:31 |
| tgardner | pgraner, wl ? | 17:31 |
| tgardner | pgraner, the driver has to register with rfkill before its displayed as an rfkillable device. | 17:32 |
| mjg59 | pgraner: Try loading hp-wmi | 17:34 |
| pgraner | mjg59: that did it now I get hp-wifi & whp-bluetooth & hci0 but no wired | 17:39 |
| mjg59 | Oh, right. This is an hp mini? | 17:40 |
| mjg59 | They do something odd in the bios where if you boot without ethernet connected, it powers down the phy | 17:40 |
| mjg59 | And then you get to read lots of 0xff rather than data | 17:40 |
| pgraner | mjg59: nice | 17:41 |
| tgardner | mjg59, thats a sky2 ? | 17:41 |
| mjg59 | rfkill doesn't cover wired, so that won't help (and hp's bios interface doesn't give you access to wired state as far as I know) | 17:41 |
| akgraner | apw, ok I just rebooted in i915.powersave=0 what do you want me note if it happens again? | 17:43 |
| apw | akgraner, yeah ... intrested to know if that is the trigger | 17:47 |
| * cking starts installing - back in a while | 17:48 | |
| manjo | JFo, apw, how do I get to the arsenal scripts? | 17:58 |
| manjo | is there a wiki some place ? | 17:59 |
| manjo | apw, https://launchpad.net/~arsenal-devel is that the same ? | 18:02 |
| apw | manjo, no, its a branch under canonical-kernel-team i think | 18:02 |
| ogasawara | manjo: https://code.edge.launchpad.net/~canonical-kernel-team/arsenal/kernel | 18:03 |
| JFo | manjo, https://code.edge.launchpad.net/~canonical-kernel-team/arsenal/kernel | 18:03 |
| JFo | dang | 18:03 |
| ogasawara | I win :) | 18:03 |
| JFo | just missed it ;) | 18:03 |
| * manjo uses ogasawara 's link | 18:03 | |
| * JFo gives ogasawara more cake | 18:03 | |
| JFo | dude, I am totally ordering a cake for your birthday ;) | 18:04 |
| JFo | heh | 18:04 |
| * manjo has a cake in his fridge | 18:05 | |
| JFo | <-jealous | 18:05 |
| manjo | bzr is freaking slow ! | 18:07 |
| manjo | JFo, should I do as the README says ? ie install those dependencies ? | 18:07 |
| * JFo doesn't remember the readme | 18:08 | |
| * JFo goes to look | 18:08 | |
| manjo | JFo, how do I start running these scripts ? | 18:15 |
| JFo | dunno what you mean manjo | 18:16 |
| JFo | ./<scriptname> [-r (if this is to be a realtime and not dryrun)] <package to run against> | 18:17 |
| manjo | JFo, I bzred the source for arsenal scripts... the readme says I need to resolve some dependencies ... I installed the packages | 18:17 |
| manjo | for dependency 1. launchpadlib there are no instructions | 18:17 |
| JFo | manjo, if you are only running the scripts in contrib/linux/ then you don't need the dependencies | 18:17 |
| manjo | ah ic | 18:17 |
| JFo | well, you need that one | 18:17 |
| JFo | launchpadlib I mean | 18:17 |
| JFo | but not the others I think | 18:17 |
| JFo | manjo, I've never gotten launchpadlib to successfully work on this machine | 18:18 |
| JFo | so I have been using cranberry (which is a qa machine) | 18:19 |
| JFo | I don't know lplib is installed on any others | 18:19 |
| manjo | JFo, what I want to do is triage all the latest suspend/resume bugs | 18:19 |
| JFo | manjo, I'm already doing that for all bugs | 18:20 |
| JFo | unless I miss your point | 18:20 |
| manjo | JFo, oh coz I have an item on my blueprint where I said ... I will look at the latest suspend/resume bugs and close/respond etc | 18:20 |
| JFo | I see | 18:21 |
| JFo | well, these run against all bugs currently | 18:21 |
| manjo | JFo, https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume | 18:21 |
| JFo | so I am triaging, but not specific to any issue | 18:21 |
| JFo | right | 18:21 |
| manjo | ok | 18:21 |
| manjo | JFo, [manjo] Review current filed bugs for general trends:INPROGRESS | 18:21 |
| JFo | so if they are old, I am asking for updated testing etc. | 18:21 |
| manjo | JFo, what I do is get a list of the bugs searching lp, then I have some scripts that will extract the attachments etc and do some processing .... but I thought arsenal was a better way .. coz you are using it | 18:23 |
| manjo | but now looks like it is a little more complicated than my simple shell scrips... | 18:23 |
| manjo | JFo, I want to look for patterns in the bugs | 18:23 |
| JFo | yeah, I am not currently doing any of that | 18:23 |
| JFo | they are a bit intense | 18:24 |
| JFo | :) | 18:24 |
| manjo | JFo, don't know if bjf 's webpage does that or not | 18:24 |
| JFo | I doubt it does manjo | 18:24 |
| JFo | but string parsing and pattern match is something that I am keen to add to some scripts | 18:24 |
| JFo | mainly for duplicate detection | 18:24 |
| manjo | JFo, so using the script I downloaded if I wanted to a listing of the latest 100 suspend resume bugs what should I do ? | 18:25 |
| JFo | what script? | 18:25 |
| manjo | aresnal | 18:25 |
| JFo | I actually don't know | 18:25 |
| manjo | :) | 18:26 |
| manjo | ok | 18:26 |
| JFo | I have only used the stuff we have in contrib/linux so far | 18:26 |
| JFo | so that I can work against all of our package bugs | 18:26 |
| JFo | but I suspect it is a 'roll your own' type of framework given what I have seen | 18:26 |
| JFo | and how we have used it in the scripts I have been adjusting | 18:27 |
| manjo | k. which obviously needs python knowledge | 18:27 |
| JFo | yep | 18:27 |
| bjf | manjo, what types of string matching are you trying to do, are you searching titles or attachments (or both)? | 18:29 |
| manjo | bjf, attachments | 18:33 |
| bjf | manjo, which attachments specifically? | 18:34 |
| cking | pgraner, my sky driver2 is working fine on my HP mini with today's daily ISO: | 18:45 |
| cking | [ 1.339845] sky2 driver version 1.25 | 18:45 |
| cking | [ 1.340044] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 | 18:45 |
| cking | [ 1.340112] sky2 0000:02:00.0: setting latency timer to 64 | 18:45 |
| cking | [ 1.340252] sky2 0000:02:00.0: Yukon-2 FE+ chip revision 0 | 18:45 |
| cking | [ 1.340882] alloc irq_desc for 26 on node -1 | 18:45 |
| cking | [ 1.340890] alloc kstat_irqs on node -1 | 18:45 |
| cking | [ 1.340976] sky2 0000:02:00.0: irq 26 for MSI/MSI-X | 18:45 |
| cking | [ 1.343348] sky2 eth0: addr 00:24:81:3a:e0:7a | 18:45 |
| cking | even works when cable is plugged in after a boot - which seems to be a fix | 18:45 |
| cking | (and unplug does not panic the kernel now either) | 18:46 |
| apw | cking, hmmm not sure i am expecting that to be fixed really, but yay if it is | 18:48 |
| cking | apw, cannot argue with my results - it's always been dodgy until I just tried it with today's ISO image | 18:49 |
| * cking wonders why pgraner is having issues with the same H/W | 18:50 | |
| apw | cking, yeah not quite sure how its better tho. new firmware perhaps | 18:53 |
| cking | apw, is the "unsupported chip type 0xff" message from pgraner's machine due to a H/W fail or difference in firmware? It's hard to tell | 18:57 |
| mjg59 | cking: That's from the chip being powered down | 18:57 |
| crimsun | apw: procedural question: should I submit a request-pull to kernel-team@ if the upstream maintainer has Acked a patch to stable@kernel? (The patch in question most probably will be in 2.6.32.11; http://kernel.ubuntu.com/git?p=dtchen/ubuntu-lucid.git;a=commitdiff;h=329fdbbd27cf3cff4a27b436b57637dd2e5417e4) | 18:57 |
| apw | if it can wait until .11 releases we'll get it naturally from there, if its a bit of blocker we can apply it as a pre-stable patch if we know its going there | 18:58 |
| cking | mjg59, that's a useful insight - so what's doing that? | 18:58 |
| mjg59 | cking: The bios does it depending on the initial cable state, iirc | 18:59 |
| crimsun | apw: well, it's quite low importance (no audio without a snd-hda-intel option), so I suppose it's best to wait. Cheers. | 18:59 |
| apw | crimsun, cool. if it was a very common platform we might want to tkae it | 19:00 |
| cking | mjg59, i would have agreed with that diagnosis, however, I've powered of the hpmini, removed the ethernet cable, removed the battery, put power back in, powered up and the driver detects OK | 19:04 |
| crimsun | bjf: is it ok to add a tag to your set of triaging ("lpib")? It would normally be attached to stuttering HDA. | 19:05 |
| cking | apw, 'tis a mystery | 19:07 |
| apw | cking, yeah ... working is so good | 19:07 |
| bjf | crimsun, yes | 19:07 |
| crimsun | bjf: cheers | 19:08 |
| === Hedge|Hog is now known as Hedgehog | ||
| === Hedgehog is now known as Guest2523 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!