[01:55] what the heck, my USB-Serial adapter is now detected as an input device and not an RS232 port? [01:56] and not 10 seconds later, now, it's detected correctly [01:56] I'm so confused [02:04] exact same issue as http://www.linux-archive.org/debian-user/53249-ttyusb0-not-appearing-solved.html === smb` is now known as smb [09:11] diwic, 32 [10:19] apw, 58f6425eb92f54943878b0b3f9c1e51f99c2cb72 === ogra_ is now known as ogra === cking is now known as cking-afk === amitk is now known as amitk-afk === JanC_ is now known as JanC [11:16] hi to all [11:16] i habve a problem with acpi event [11:16] do you can help me? === amitk-afk is now known as amitk === diwic is now known as diwic_afk === diwic_afk is now known as diwic [12:48] yawn ... quiet today [12:50] * ogra makes some noise [13:21] ekoore, whats up with it? could you give some details, then someone might be able to === cking-afk is now known as cking [13:58] apw, are you still debugging something on natty? [14:00] tgardner, no i am pretty happy with it right now [14:01] tgardner, did you get a chance to 'stress' the master-next yesterday? [14:01] tgardner, working up to tying the bow, if your results are good ... [14:01] just pushing some binaries for smb et al to touch test and then it goes in [14:02] apw, yep, I dribbeled a note in IRC before leaving, but we all know how effective thath usually is. it withstood stress for an hour with loads of 130+ [14:02] tgardner, ahh excellent [14:02] the .deb will be up in 0:34 seconds apparently [14:03] apw, I'll go back to my xen headache then [14:03] * smb presses the on-button on the aspire one [14:03] smb, :) [14:03] tgardner, What kind do you have? [14:03] smb, CVE-2010-3699. do you still have a dom0 test machine? [14:03] tgardner: The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3699) [14:04] tgardner, I believe I still have the Hardy server installation, yes [14:05] * smb rumbles through the harddrive collection. Yup its there [14:05] tgardner, So let me know when you got something that needs testing [14:05] smb, can you make sure a guest still boots on a dom0 host using tangerine:~/kern/hardy/kern-64/linux-image-2.6.24-28-xen_2.6.24-28.83_amd64.deb ? [14:06] tgardner, sure. let me boot up my box [14:15] tgardner, you are aware that -28.83 is in proposed. :) testbox was whining about downgrading. :-P [14:15] I mean .84 [14:15] smb, when you get a chance: http://people.canonical.com/~apw/master-next-natty/ [14:16] apw, next thing on list [14:17] ta man [14:17] smb, hmm, must have missed it. it took me close to 4 hours to figure out this patch. [14:20] tgardner, hmm. attempt #1 -> box froze solid (no message seen but I have to switch vts to login). retrying... [14:21] smb, before you even started the guest? [14:21] tgardner, guest start was automatic from saved session [14:24] tgardner, Reboot after crash came up but without saved xen guest. And trying to start it returns an error (translated into function not implemented) [14:24] smb, shit. guess I'm gonna have to install some bare metal. [14:25] tgardner, For your own test system? [14:25] smb, yep [14:26] smb, unless you wanna debug this [14:27] tgardner, If you shove your patch over I can have a look. [14:27] There is not much on dmesg you can see [14:27] * apw opens his window, yep that is tangerine i can hear howling [14:27] smb, the patch and pull request are on the k-t list [14:28] tgardner, ok, I will put it on my list [14:28] apw, is next though [14:28] apw, So I guess I should not put another buld on it. :) [14:32] heh [14:36] smb, [14:36] smb, heh i am sure she won't mind [14:37] apw, Not quite ready yet, but soonish I may try scary-patch v2 for Lucid === zul_ is now known as zul [14:45] apw, Ok, aspire one came up has screen and wireless and no obvious new complaints from acpi with your latest natty kernel [14:54] smb, most gratifying [14:54] hi apw [14:54] apw, do you can help me? [14:56] ekoore, so does the screen turn off in grub etc ? i assume not ? [14:56] not, it poweroff only after grub [14:57] ekoore, and presumably only once we get to userspace, i assume something there is responding to it. does the device have a network you could ssh in over and watch to see what is getting generated when the twist happens [14:57] input-events might tell you ... [14:58] yes [15:00] do you want the ip of the machine? [15:01] not really got time to poke it right now, trying to get the natty kernel sewn up [15:01] but i suggest you try and work out what key is getting generated in userspae [15:01] that likely can be disconnected [15:02] i have the same problem in usersace [15:03] can i do the comand for sisabling it, to the start of boot sequence, and not to the end, with rc.local? [15:07] what is the version of the kernel in natty? [15:07] ekoore, its going to be .38 [15:08] ok i understand [15:19] ekoore, ok i've had a bit of a poke and cannot see an easy way to turn it off early [15:19] it seems to get turned on the first time when the consumer of the gpe starts, but i have no way to know [15:19] what might be triggering that [15:22] is not possible disabling it from the kernel source? [15:22] ekoore, i am sure you can change the kernel to prevent it being enabled, there is no obvious mechanism in there already to do so [15:22] ekoore, the assumption is that your bios asks for things to be enabled which make sense and it enabled them [15:25] i am told that a gpe11 would trigger methods _L0B or _E0B would be called as a result of that interrupt occuring and those must be triggering the blackness ... looking at those may be fruitful as you have the bios [15:27] apw, yes, but where is configurated the triggering of the blackness? [15:27] ekoore, the kernel will respond to gpe11 by calling the acpi methods listed above. what those do is bios specific [15:28] the kernel does only what it is told to by the bios on those cases (as i understand it) [15:29] yes, i think that is a problem of the bios, but i want solve in the kernel [15:30] ekoore, well the kernel has no feature to turn off gpes by default as far as i can tell, so you'd have to add one, or bitch at your bios vendor [15:30] acpi_hw_low_set_gpe() seems to be the low level enable routine, somewhere in the call chain for that you'd want to add something to suppress it [15:31] with windows os, i don't have this problem [15:32] * sforshee -> reboot [15:32] ekoore, and i am sure the kernel there has been modified to handle the bios brokeness [15:32] ekoore, as i am sure it has a machine specific module to handle this kind of thing [15:33] ekoore, as i say there isn't obviously a way to handle it without writing some code [15:33] ekoore, apparently noone has had this issue before, or if they have they have managed to get their bios fixed === bjf[afk] is now known as bjf [15:38] in with way i can have the fix of the bios? [15:38] is needed the source? [15:38] or i can disassemble it? [15:38] ekoore, normally you report your issue to them and they fix it as far as i can tell [15:38] ekoore, fixing the BIOS is not easy - you need to engage with the vendor [15:40] is impossible solve from linux kernel? [15:40] ekoore, no not impossible. just you need to write some code, as it is not already there [15:41] yes i understand, do you can help me in this? [15:41] i don't have the time i am afraid, no [15:44] is possible do a comand after the loading of the kernel? === sconklin-afk is now known as sconklin [15:46] ekoore, not early enough to guarentee you cannot ever his the issue [15:48] the only easy way to get insight at this point is to see if there any _L0B, _E0B methods in the ACPI DSDT and then see what they are doing [15:48] ..but you need to understand the AML code, which is a pain [15:52] ekoore, http://smackerelofopinion.blogspot.com/2009/10/dumping-acpi-tables-using-acpidump-and.html and http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html maybe useful [15:55] http://www.pat-testing.info/recallnotice/sony-vaio.htm overheating Vaios due to a "firmware" problem [16:05] tgardner, did the armel natty chroots get updated? i am seeing 'cp15 insn xxxx' blammos from qemu [16:06] apw, the natty armel chroots still don't work, so I disabled them [16:07] tgardner, oh i thought we had stale ones and they sort of worked [16:07] apw, I should remove the one on tangerine [16:07] apw, I probably messed up and did an update [16:08] ogra mumbled something at me about using Maverick debootstrap or qemu, but I never followed up on his suggestion [16:08] hmm ? [16:08] natty armel chroot [16:09] yeah, i got that, whats your prob ? [16:09] it don't work [16:09] hmm, i havent used x86 hosts for a while, they should work though [16:09] ogra, gimme a bit, I can produce some error messages. it generally wedges the qemu session [16:10] k [16:12] ogra, https://pastebin.canonical.com/42364/ [16:13] hmm, whats the command you used there ? [16:14] looks like an issue with your arch, is that amd64 or x86 ? [16:14] qemu-debootstrap --arch=armel natty /usr3/chroots/natty-armel http://mirror.rtg.net/ubuntu-ports [16:14] I: Running command: debootstrap --arch armel --foreign natty /usr3/chroots/natty-armel http://mirror.rtg.net/ubuntu-ports [16:14] i think i have seen such an error on amd64 but not on x86 [16:14] amd64 [16:14] ogra, who has 32 bit servers these days? [16:15] i do ... arm doesnt have 64bits yet :) [16:16] ogra, well, all of my dev boxes have a zillion CPUs, so i386 doesn't make sense on them [16:16] well, but it sounds like a bug, if you have no option to build on an x86 machine i would suggest building a maverick chroot and dist upgrade that [16:17] ogra, k, I'll try that [16:23] sconklin, how is the SRU testing going? [16:24] tgardner: ask cert and qa [16:24] I don't know, and they don't have any status pages that I'm aware of [16:25] sconklin, they've got this one: http://people.canonical.com/~hwcert/sru-testing/current/ [16:25] well ok, then, there's your answer [16:26] sconklin, the reason I ask is that there are some non-zero numbers in the failures column and wondered if you're getting push back on some of the patches [16:27] tgardner: in every case in the past, those have turned out to all be false negatives, and the cert team has given them a pass. [16:28] But it's a good question [16:28] sconklin, hmm, ok [16:29] I wish there was more detail about the tests [16:30] sru_disk_buf_read_perf_adv_tes doesn't mean anything to me [16:30] but I suspect a result of "command not found" is not a kernel problem [16:30] sconklin, I suppose next you'll be wanting a link to the test source code :) [16:31] sru_sleep_state_test failure looks like it may actually be a failure - that one is more worrisome [16:32] is that an S3 test I wonder ? [16:32] hmm, if you drill down, at least the first one if marked "Unresolved", while the second if fail. But they both show as fails on the status page [16:32] ogra, no joy on dist-upgrade from maverick to natty, same basic error [16:33] but bootstrappping natty worked ? [16:33] err [16:33] maverick [16:33] ogra, yes, maverick works [16:33] hmpf [16:35] all ogra's fault clearly [16:35] i didnt touch qemu since 2 releases [16:35] its your crappy hardware, use arm cortex-a15 :P [16:36] can also have 100s of cores and terabytes of ram [16:36] ogra, well, we normally cross compile, but some stuff really requires a native armel environment. [16:36] yeah [16:37] i really dont know what makes qemu fail there, i know that slangasek is working on a new package from a different source for exactly the armel stuff [16:37] but i dont know where that stands [16:38] ogra, if I filed a bug, would it be against qemu-kvm-extras-static ? [16:38] yes, thats what holds the binfmt handlers [16:39] k [16:40] tgardner, yeah like the perf packages cause we don't support cross compilation in the archive [16:42] apw, smb, tgardner, https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs [17:04] ogra, tgardner: the plan is that qemu-kvm-extras-static gets taken over by a new qemu-linaro source package as a transitional package [17:04] apw, cking, i am here === cmagina is now known as cmagina-lunch [17:05] slangasek, sometime soon? [17:05] tgardner: within the week [17:05] slangasek, cool. I'll watch for it [17:08] <- lunch and an errand... I hate taxes. :-/ [17:11] slangasek, I assume your natty qemu-kvm-extras-static will work in a debootstrap on a lucid host? [17:30] tgardner: I also assume this :) [17:30] (I don't have any evidence one way or the other at the moment, but if it doesn't work, we'll want to fix it) [17:31] slangasek, i thought those packages were installed in the host, and loaded via init. so wouldn't you need a native package to make it work in chroots ? [17:31] via the bin_fmt_misc thingy [17:31] apw: well, we will be providing backported packages [17:31] in the linaro ppa [17:32] slangasek, that makes sense to me, cool [17:32] is it ready yet, is it ready yet [17:32] apw: but if you're doing interpreter resolution in a chroot, the paths are resolved relative to the chroot [17:33] slangasek, they are, oh hrm really? [17:33] (qemu has multiple modes for this stuff and I never remember which name is which... but if you've got an x86 chroot with a smattering of arm executables, that's all done within the chroot) [17:33] apw: sure, otherwise it's an instant jailbreak :) [17:33] slangasek, heh well i guess that makes sense and everything === bjf is now known as bjf[afk] === cmagina-lunch is now known as cmagina === sforshee is now known as sforshee-lunch [18:20] slangasek, i think i am thinking of the armel chroot all armel inside case ... but anyhow i am sure we will work it out when they exist [18:49] * tgardner --> lunch === sforshee-lunch is now known as sforshee === bjf[afk] is now known as bjf [19:28] smb, using stock 8.04.1 and http://www.howtoforge.com/ubuntu-8.04-server-install-xen-from-ubuntu-repositories I was able to boot a xen image [19:39] apw, root@e1501:~# cat /proc/version [19:39] Linux version 2.6.24-28-xen (buildd@crested) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Wed Nov 24 10:58:54 UTC 2010 [19:39] root@e1501:~# cat /proc/version_signature [19:39] Ubuntu 2.6.24-4.6-generic [19:39] root@e1501:~# [19:41] apw, root@e1501:/boot# ls -l [19:41] total 36140 [19:41] -rw-r--r-- 1 root root 420224 2008-06-18 10:51 abi-2.6.24-19-server [19:41] -rw-r--r-- 1 root root 74169 2008-06-18 10:51 config-2.6.24-19-server [19:41] -rw-r--r-- 1 root root 82909 2010-11-24 04:59 config-2.6.24-28-xen [19:41] drwxr-xr-x 2 root root 4096 2011-01-26 11:50 grub [19:41] -rw-r--r-- 1 root root 7517611 2011-01-26 11:39 initrd.img-2.6.24-19-server [19:41] -rw-r--r-- 1 root root 7239178 2011-01-26 11:32 initrd.img-2.6.24-19-server.bak [19:41] -rw-r--r-- 1 root root 7468145 2011-01-26 11:50 initrd.img-2.6.24-28-xen [19:41] -rw-r--r-- 1 root root 7467768 2011-01-26 11:50 initrd.img-2.6.24-28-xen.bak [19:41] -rw-r--r-- 1 root root 103204 2007-09-28 05:03 memtest86+.bin [19:41] -rw-r--r-- 1 root root 1162275 2008-06-18 10:51 System.map-2.6.24-19-server [19:42] -rw-r--r-- 1 root root 1129165 2010-11-24 04:59 System.map-2.6.24-28-xen [19:42] -rw-r--r-- 1 root root 1928216 2008-06-18 10:51 vmlinuz-2.6.24-19-server [19:42] -rw-r--r-- 1 root root 1895911 2010-11-24 04:59 vmlinuz-2.6.24-28-xen [19:42] -rw-r--r-- 1 root root 401328 2009-02-20 20:04 xen-3.2.gz [19:43] apw, debian/config/amd64/config.generic:CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-4.6-generic" [19:45] debian/rules.d/2-binary-arch.mk: cat $^ | sed -e 's/.*CONFIG_VERSION_SIGN [20:11] tgardner, Ok, it really was the xen-3.3 stuff I took from hardy-backports. Thrown everything away and now had no problem in booting the kernel with the updated patch and run a new domU [20:13] smb, otp, back in a sec [20:17] smb, http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/59f097ef181b [20:31] JFo: wrt to this kernel bug handling work item its just reviewing the existing kernel team debugging procedures right? [20:32] JFo: the one assigned to me [20:33] hmmmm, let me look [20:34] I believe it was more to do with getting the qa team looking there for some reason, but I don't recall precisely [20:34] or perhaps there was some documentation that was needed [20:35] I can't recall [20:35] let me see if I can find my notes [20:35] What I recall is you all wanted somebody outside the kernel team to review the rewritten debugging procedures and I believe Kamal mentioned grub and boot options. [20:36] ah, that tickles a memory [20:36] bdmurray, JFo: um... I recently added this to the kernel team FAQ: https://wiki.ubuntu.com/Kernel/FAQ#How do I add a Kernel Boot Parameter? [20:37] make that: https://wiki.ubuntu.com/Kernel/KernelBootParameters [20:38] very nice kamal [20:38] (if that's even relevant to your conversation :-) [20:38] :) [20:38] so its stuff like that I / my team is supposed to review [20:39] bdmurray, your recollection works for me as I seem to have relocated my notebook (tax season) [20:39] bdmurray: I should have told somebody (you) about it I guess! ooops. [20:39] JFo: okay, I'll clarify the work item so its more definitive [20:40] thank you sir [21:55] How do I see what a given file looked like at a given revision with git? [21:57] I *think* git show $SHA:path/to/file works === sconklin is now known as sconklin-gone === bjf is now known as bjf[afk]