[01:55] <lucent> what the heck, my USB-Serial adapter is now detected as an input device and not an RS232 port?
[01:56] <lucent> and not 10 seconds later, now, it's detected correctly
[01:56] <lucent> I'm so confused
[02:04] <lucent> exact same issue as http://www.linux-archive.org/debian-user/53249-ttyusb0-not-appearing-solved.html
[09:11] <apw> diwic, 32
[10:19] <cking> apw, 58f6425eb92f54943878b0b3f9c1e51f99c2cb72
[11:16] <ekoore> hi to all
[11:16] <ekoore> i habve a problem with acpi event
[11:16] <ekoore> do you can help me?
[12:48] <apw_> yawn ... quiet today
[12:50]  * ogra makes some noise
[13:21] <apw> ekoore, whats up with it?  could you give some details, then someone might be able to
[13:58] <tgardner> apw, are you still debugging something on natty?
[14:00] <apw> tgardner, no i am pretty happy with it right now
[14:01] <apw> tgardner, did you get a chance to 'stress' the master-next yesterday?
[14:01] <apw> tgardner, working up to tying the bow, if your results are good ...
[14:01] <apw> just pushing some binaries for smb et al to touch test and then it goes in
[14:02] <tgardner> 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] <apw> tgardner, ahh excellent
[14:02] <apw> the .deb will be up in 0:34 seconds apparently
[14:03] <tgardner> apw, I'll go back to my xen headache then
[14:03]  * smb presses the on-button on the aspire one
[14:03] <apw> smb, :)
[14:03] <smb> tgardner, What kind do you have?
[14:03] <tgardner> smb, CVE-2010-3699. do you still have a dom0 test machine?
[14:03] <ubot2> 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] <smb> tgardner, I believe I still have the Hardy server installation, yes
[14:05]  * smb rumbles through the harddrive collection. Yup its there
[14:05] <smb> tgardner, So let me know when you got something that needs testing
[14:05] <tgardner> 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] <smb> tgardner, sure. let me boot up my box
[14:15] <smb> tgardner, you are aware that -28.83 is in proposed. :) testbox was whining about downgrading. :-P
[14:15] <smb> I mean .84
[14:15] <apw> smb, when you get a chance: http://people.canonical.com/~apw/master-next-natty/
[14:16] <smb> apw, next thing on list
[14:17] <apw> ta man
[14:17] <tgardner> smb, hmm, must have missed it. it took me close to 4 hours to figure out this patch.
[14:20] <smb> tgardner, hmm. attempt  #1 -> box froze solid (no message seen but I have to switch vts to login). retrying...
[14:21] <tgardner> smb, before you even started the guest?
[14:21] <smb> tgardner, guest start was automatic from saved session
[14:24] <smb> 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] <tgardner> smb, shit. guess I'm gonna have to install some bare metal.
[14:25] <smb> tgardner, For your own test system?
[14:25] <tgardner> smb, yep
[14:26] <tgardner> smb, unless you wanna debug this
[14:27] <smb> tgardner, If you shove your patch over I can have a look. 
[14:27] <smb> 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] <tgardner> smb, the patch and pull request are on the k-t list
[14:28] <smb> tgardner, ok, I will put it on my list
[14:28] <smb> apw, is next though
[14:28] <smb> apw, So I guess I should not put another buld on it. :)
[14:32] <JFo> heh
[14:36] <apw> smb, 
[14:36] <apw> smb, heh i am sure she won't mind
[14:37] <smb> apw, Not quite ready yet, but soonish I may try scary-patch v2 for Lucid
[14:45] <smb> apw, Ok, aspire one came up has screen and wireless and no obvious new complaints from acpi with your latest natty kernel
[14:54] <apw> smb, most gratifying
[14:54] <ekoore> hi apw
[14:54] <ekoore> apw, do you can help me?
[14:56] <apw> ekoore, so does the screen turn off in grub etc ?  i assume not ?
[14:56] <ekoore> not, it poweroff only after grub
[14:57] <apw> 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] <apw> input-events might tell you ...
[14:58] <ekoore> yes
[15:00] <ekoore> do you want the ip of the machine?
[15:01] <apw> not really got time to poke it right now, trying to get the natty kernel sewn up
[15:01] <apw> but i suggest you try and work out what key is getting generated in userspae
[15:01] <apw> that likely can be disconnected
[15:02] <ekoore> i have the same problem in usersace
[15:03] <ekoore> can i do the comand for sisabling it, to the start of boot sequence, and not to the end, with rc.local?
[15:07] <ekoore> what is the version of the kernel in natty?
[15:07] <apw> ekoore, its going to be .38
[15:08] <ekoore> ok i understand
[15:19] <apw> ekoore, ok i've had a bit of a poke and cannot see an easy way to turn it off early
[15:19] <apw> 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] <apw> what might be triggering that
[15:22] <ekoore> is not possible disabling it from the kernel source?
[15:22] <apw> 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] <apw> ekoore, the assumption is that your bios asks for things to be enabled which make sense and it enabled them
[15:25] <apw> 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] <ekoore> apw, yes, but where is configurated the triggering of the blackness?
[15:27] <apw> ekoore, the kernel will respond to gpe11 by calling the acpi methods listed above.  what those do is bios specific
[15:28] <apw> the kernel does only what it is told to by the bios on those cases (as i understand it)
[15:29] <ekoore> yes, i think that is a problem of the bios, but i want solve in the kernel
[15:30] <apw> 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] <apw> 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] <ekoore> with windows os, i don't have this problem
[15:32]  * sforshee -> reboot
[15:32] <apw> ekoore, and i am sure the kernel there has been modified to handle the bios brokeness
[15:32] <apw> ekoore, as i am sure it has a machine specific module to handle this kind of thing
[15:33] <apw> ekoore, as i say there isn't obviously a way to handle it without writing some code
[15:33] <apw> ekoore, apparently noone has had this issue before, or if they have they have managed to get their bios fixed
[15:38] <ekoore> in with way i can have the fix of the bios?
[15:38] <ekoore> is needed the source?
[15:38] <ekoore> or i can disassemble it?
[15:38] <apw> ekoore, normally you report your issue to them and they fix it as far as i can tell
[15:38] <cking> ekoore, fixing the BIOS is not easy - you need to engage with the vendor
[15:40] <ekoore> is impossible solve from linux kernel?
[15:40] <apw> ekoore, no not impossible.  just you need to write some code, as it is not already there
[15:41] <ekoore> yes i understand, do you can help me in this?
[15:41] <apw> i don't have the time i am afraid, no
[15:44] <ekoore> is possible do a comand after the loading of the kernel?
[15:46] <apw> ekoore, not early enough to guarentee you cannot ever his the issue
[15:48] <cking> 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] <cking> ..but you need to understand the AML code, which is a pain
[15:52] <cking> 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] <sconklin> http://www.pat-testing.info/recallnotice/sony-vaio.htm overheating Vaios due to a "firmware" problem
[16:05] <apw> tgardner, did the armel natty chroots get updated?  i am seeing 'cp15 insn xxxx' blammos from qemu
[16:06] <tgardner> apw, the natty armel chroots still don't work, so I disabled them
[16:07] <apw> tgardner, oh i thought we had stale ones and they sort of worked
[16:07] <tgardner> apw, I should remove the one on tangerine
[16:07] <tgardner> apw, I probably messed up and did an update
[16:08] <tgardner> ogra mumbled something at me about using Maverick debootstrap or qemu, but I never followed up on his suggestion
[16:08] <ogra> hmm ?
[16:08] <tgardner> natty armel chroot
[16:09] <ogra> yeah, i got that, whats your prob ?
[16:09] <tgardner> it don't work
[16:09] <ogra> hmm, i havent used x86 hosts for a while, they should work though
[16:09] <tgardner> ogra, gimme a bit, I can produce some error messages. it generally wedges the qemu session
[16:10] <ogra> k
[16:12] <tgardner> ogra, https://pastebin.canonical.com/42364/
[16:13] <ogra> hmm, whats the command you used there ? 
[16:14] <ogra> looks like an issue with your arch, is that amd64 or x86 ?
[16:14] <tgardner> qemu-debootstrap --arch=armel natty /usr3/chroots/natty-armel http://mirror.rtg.net/ubuntu-ports
[16:14] <tgardner> I: Running command: debootstrap --arch armel --foreign natty /usr3/chroots/natty-armel http://mirror.rtg.net/ubuntu-ports
[16:14] <ogra> i think i have seen such an error on amd64 but not on x86
[16:14] <tgardner> amd64
[16:14] <tgardner> ogra, who has 32 bit servers these days?
[16:15] <ogra> i do ... arm doesnt have 64bits yet :)
[16:16] <tgardner> ogra, well, all of my dev boxes have a zillion CPUs, so i386 doesn't make sense on them
[16:16] <ogra> 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] <tgardner> ogra, k, I'll try that
[16:23] <tgardner> sconklin, how is the SRU testing going?
[16:24] <sconklin> tgardner: ask cert and qa
[16:24] <sconklin> I don't know, and they don't have any status pages that I'm aware of
[16:25] <tgardner> sconklin, they've got this one: http://people.canonical.com/~hwcert/sru-testing/current/
[16:25] <sconklin> well ok, then, there's your answer
[16:26] <tgardner> 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] <sconklin> 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] <sconklin> But it's a good question
[16:28] <tgardner> sconklin, hmm, ok
[16:29] <sconklin> I wish there was more detail about the tests
[16:30] <sconklin> sru_disk_buf_read_perf_adv_tes doesn't mean anything to me
[16:30] <sconklin> but I suspect a result of "command not found" is not a kernel problem
[16:30] <tgardner> sconklin, I suppose next you'll be wanting a link to the test source code :)
[16:31] <sconklin> sru_sleep_state_test failure looks like it may actually be a failure - that one is more worrisome
[16:32] <tgardner> is that an S3 test I wonder ?
[16:32] <sconklin> 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] <tgardner> ogra, no joy on dist-upgrade from maverick to natty, same basic error
[16:33] <ogra> but bootstrappping natty worked ?
[16:33] <ogra> err
[16:33] <ogra> maverick
[16:33] <tgardner> ogra, yes, maverick works
[16:33] <ogra> hmpf
[16:35] <apw> all ogra's fault clearly
[16:35] <ogra> i didnt touch qemu since 2 releases
[16:35] <ogra> its your crappy hardware, use arm cortex-a15 :P
[16:36] <ogra> can also have 100s of cores and terabytes of ram
[16:36] <tgardner> ogra, well, we normally cross compile, but some stuff really requires a native armel environment.
[16:36] <ogra> yeah
[16:37] <ogra> 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] <ogra> but i dont know where that stands
[16:38] <tgardner> ogra, if I filed a bug, would it be against qemu-kvm-extras-static ?
[16:38] <ogra> yes, thats what holds the binfmt handlers
[16:39] <tgardner> k
[16:40] <apw> tgardner, yeah like the perf packages cause we don't support cross compilation in the archive
[16:42] <bjf> apw, smb, tgardner, https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs
[17:04] <slangasek> 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] <ekoore> apw, cking, i am here
[17:05] <tgardner> slangasek, sometime soon?
[17:05] <slangasek> tgardner: within the week
[17:05] <tgardner> slangasek, cool. I'll watch for it
[17:08] <JFo> <- lunch and an errand... I hate taxes. :-/
[17:11] <tgardner> slangasek, I assume your natty qemu-kvm-extras-static will work in a debootstrap on a lucid host?
[17:30] <slangasek> tgardner: I also assume this :)
[17:30] <slangasek> (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] <apw> slangasek, i thought those packages were installed in the host, and loaded via init.  so wouldn't you need a native <host release> package to make it work in chroots ?
[17:31] <apw> via the bin_fmt_misc thingy
[17:31] <slangasek> apw: well, we will be providing backported packages
[17:31] <slangasek> in the linaro ppa
[17:32] <apw> slangasek, that makes sense to me, cool
[17:32] <apw> is it ready yet, is it ready yet
[17:32] <slangasek> apw: but if you're doing interpreter resolution in a chroot, the paths are resolved relative to the chroot
[17:33] <apw> slangasek, they are, oh hrm really?
[17:33] <slangasek> (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] <slangasek> apw: sure, otherwise it's an instant jailbreak :)
[17:33] <apw> slangasek, heh well i guess that makes sense and everything
[18:20] <apw> 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
[19:28] <tgardner> 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] <tgardner> apw, root@e1501:~# cat /proc/version
[19:39] <tgardner> 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] <tgardner> root@e1501:~# cat /proc/version_signature 
[19:39] <tgardner> Ubuntu 2.6.24-4.6-generic
[19:39] <tgardner> root@e1501:~#
[19:41] <tgardner> apw, root@e1501:/boot# ls -l
[19:41] <tgardner> total 36140
[19:41] <tgardner> -rw-r--r-- 1 root root  420224 2008-06-18 10:51 abi-2.6.24-19-server
[19:41] <tgardner> -rw-r--r-- 1 root root   74169 2008-06-18 10:51 config-2.6.24-19-server
[19:41] <tgardner> -rw-r--r-- 1 root root   82909 2010-11-24 04:59 config-2.6.24-28-xen
[19:41] <tgardner> drwxr-xr-x 2 root root    4096 2011-01-26 11:50 grub
[19:41] <tgardner> -rw-r--r-- 1 root root 7517611 2011-01-26 11:39 initrd.img-2.6.24-19-server
[19:41] <tgardner> -rw-r--r-- 1 root root 7239178 2011-01-26 11:32 initrd.img-2.6.24-19-server.bak
[19:41] <tgardner> -rw-r--r-- 1 root root 7468145 2011-01-26 11:50 initrd.img-2.6.24-28-xen
[19:41] <tgardner> -rw-r--r-- 1 root root 7467768 2011-01-26 11:50 initrd.img-2.6.24-28-xen.bak
[19:41] <tgardner> -rw-r--r-- 1 root root  103204 2007-09-28 05:03 memtest86+.bin
[19:41] <tgardner> -rw-r--r-- 1 root root 1162275 2008-06-18 10:51 System.map-2.6.24-19-server
[19:42] <tgardner> -rw-r--r-- 1 root root 1129165 2010-11-24 04:59 System.map-2.6.24-28-xen
[19:42] <tgardner> -rw-r--r-- 1 root root 1928216 2008-06-18 10:51 vmlinuz-2.6.24-19-server
[19:42] <tgardner> -rw-r--r-- 1 root root 1895911 2010-11-24 04:59 vmlinuz-2.6.24-28-xen
[19:42] <tgardner> -rw-r--r-- 1 root root  401328 2009-02-20 20:04 xen-3.2.gz
[19:43] <tgardner> apw, debian/config/amd64/config.generic:CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-4.6-generic"
[19:45] <apw> debian/rules.d/2-binary-arch.mk:        cat $^ | sed -e 's/.*CONFIG_VERSION_SIGN
[20:11] <smb> 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] <tgardner> smb, otp, back in a sec
[20:17] <tgardner> smb, http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/59f097ef181b
[20:31] <bdmurray> JFo: wrt to this kernel bug handling work item its just reviewing the existing kernel team debugging procedures right?
[20:32] <bdmurray> JFo: the one assigned to me
[20:33] <JFo> hmmmm, let me look
[20:34] <JFo> 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] <JFo> or perhaps there was some documentation that was needed
[20:35] <JFo> I can't recall
[20:35] <JFo> let me see if I can find my notes
[20:35] <bdmurray> 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] <JFo> ah, that tickles a memory
[20:36] <kamal> 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] <kamal> make that:  https://wiki.ubuntu.com/Kernel/KernelBootParameters
[20:38] <JFo> very nice kamal 
[20:38] <kamal> (if that's even relevant to your conversation :-)
[20:38] <JFo> :)
[20:38] <bdmurray> so its stuff like that I / my team is supposed to review
[20:39] <JFo> bdmurray, your recollection works for me as I seem to have relocated my notebook (tax season)
[20:39] <kamal> bdmurray: I should have told somebody (you) about it I guess!  ooops.
[20:39] <bdmurray> JFo: okay, I'll clarify the work item so its more definitive
[20:40] <JFo> thank you sir
[21:55] <soren> How do I see what a given file looked like at a given revision with git?
[21:57] <RAOF> I *think* git show $SHA:path/to/file works