lucent | what the heck, my USB-Serial adapter is now detected as an input device and not an RS232 port? | 01:55 |
---|---|---|
lucent | and not 10 seconds later, now, it's detected correctly | 01:56 |
lucent | I'm so confused | 01:56 |
lucent | exact same issue as http://www.linux-archive.org/debian-user/53249-ttyusb0-not-appearing-solved.html | 02:04 |
=== smb` is now known as smb | ||
apw | diwic, 32 | 09:11 |
cking | apw, 58f6425eb92f54943878b0b3f9c1e51f99c2cb72 | 10:19 |
=== 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 | ||
ekoore | hi to all | 11:16 |
ekoore | i habve a problem with acpi event | 11:16 |
ekoore | do you can help me? | 11:16 |
=== amitk-afk is now known as amitk | ||
=== diwic is now known as diwic_afk | ||
=== diwic_afk is now known as diwic | ||
apw_ | yawn ... quiet today | 12:48 |
* ogra makes some noise | 12:50 | |
apw | ekoore, whats up with it? could you give some details, then someone might be able to | 13:21 |
=== cking-afk is now known as cking | ||
tgardner | apw, are you still debugging something on natty? | 13:58 |
apw | tgardner, no i am pretty happy with it right now | 14:00 |
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:01 |
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:02 |
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:03 |
smb | tgardner, I believe I still have the Hardy server installation, yes | 14:04 |
* 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:05 |
smb | tgardner, sure. let me boot up my box | 14:06 |
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:15 |
smb | apw, next thing on list | 14:16 |
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:17 |
smb | tgardner, hmm. attempt #1 -> box froze solid (no message seen but I have to switch vts to login). retrying... | 14:20 |
tgardner | smb, before you even started the guest? | 14:21 |
smb | tgardner, guest start was automatic from saved session | 14:21 |
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:24 |
smb | tgardner, For your own test system? | 14:25 |
tgardner | smb, yep | 14:25 |
tgardner | smb, unless you wanna debug this | 14:26 |
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:27 |
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:28 |
JFo | heh | 14:32 |
apw | smb, | 14:36 |
apw | smb, heh i am sure she won't mind | 14:36 |
smb | apw, Not quite ready yet, but soonish I may try scary-patch v2 for Lucid | 14:37 |
=== zul_ is now known as zul | ||
smb | apw, Ok, aspire one came up has screen and wireless and no obvious new complaints from acpi with your latest natty kernel | 14:45 |
apw | smb, most gratifying | 14:54 |
ekoore | hi apw | 14:54 |
ekoore | apw, do you can help me? | 14:54 |
apw | ekoore, so does the screen turn off in grub etc ? i assume not ? | 14:56 |
ekoore | not, it poweroff only after grub | 14:56 |
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:57 |
ekoore | yes | 14:58 |
ekoore | do you want the ip of the machine? | 15:00 |
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:01 |
ekoore | i have the same problem in usersace | 15:02 |
ekoore | can i do the comand for sisabling it, to the start of boot sequence, and not to the end, with rc.local? | 15:03 |
ekoore | what is the version of the kernel in natty? | 15:07 |
apw | ekoore, its going to be .38 | 15:07 |
ekoore | ok i understand | 15:08 |
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:19 |
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:22 |
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:25 |
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:27 |
apw | the kernel does only what it is told to by the bios on those cases (as i understand it) | 15:28 |
ekoore | yes, i think that is a problem of the bios, but i want solve in the kernel | 15:29 |
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:30 |
ekoore | with windows os, i don't have this problem | 15:31 |
* 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:32 |
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:33 |
=== bjf[afk] is now known as bjf | ||
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:38 |
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:40 |
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:41 |
ekoore | is possible do a comand after the loading of the kernel? | 15:44 |
=== sconklin-afk is now known as sconklin | ||
apw | ekoore, not early enough to guarentee you cannot ever his the issue | 15:46 |
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:48 |
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:52 |
sconklin | http://www.pat-testing.info/recallnotice/sony-vaio.htm overheating Vaios due to a "firmware" problem | 15:55 |
apw | tgardner, did the armel natty chroots get updated? i am seeing 'cp15 insn xxxx' blammos from qemu | 16:05 |
tgardner | apw, the natty armel chroots still don't work, so I disabled them | 16:06 |
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:07 |
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:08 |
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:09 |
ogra | k | 16:10 |
tgardner | ogra, https://pastebin.canonical.com/42364/ | 16:12 |
ogra | hmm, whats the command you used there ? | 16:13 |
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:14 |
ogra | i do ... arm doesnt have 64bits yet :) | 16:15 |
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:16 |
tgardner | ogra, k, I'll try that | 16:17 |
tgardner | sconklin, how is the SRU testing going? | 16:23 |
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:24 |
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:25 |
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:26 |
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:27 |
sconklin | But it's a good question | 16:28 |
tgardner | sconklin, hmm, ok | 16:28 |
sconklin | I wish there was more detail about the tests | 16:29 |
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:30 |
sconklin | sru_sleep_state_test failure looks like it may actually be a failure - that one is more worrisome | 16:31 |
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:32 |
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:33 |
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:35 |
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:36 |
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:37 |
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:38 |
tgardner | k | 16:39 |
apw | tgardner, yeah like the perf packages cause we don't support cross compilation in the archive | 16:40 |
bjf | apw, smb, tgardner, https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs | 16:42 |
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:04 |
=== cmagina is now known as cmagina-lunch | ||
tgardner | slangasek, sometime soon? | 17:05 |
slangasek | tgardner: within the week | 17:05 |
tgardner | slangasek, cool. I'll watch for it | 17:05 |
JFo | <- lunch and an errand... I hate taxes. :-/ | 17:08 |
tgardner | slangasek, I assume your natty qemu-kvm-extras-static will work in a debootstrap on a lucid host? | 17:11 |
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:30 |
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:31 |
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:32 |
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 | 17:33 |
=== bjf is now known as bjf[afk] | ||
=== cmagina-lunch is now known as cmagina | ||
=== sforshee is now known as sforshee-lunch | ||
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:20 |
* tgardner --> lunch | 18:49 | |
=== sforshee-lunch is now known as sforshee | ||
=== bjf[afk] is now known as bjf | ||
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:28 |
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:39 |
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:41 |
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:42 |
tgardner | apw, debian/config/amd64/config.generic:CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-4.6-generic" | 19:43 |
apw | debian/rules.d/2-binary-arch.mk: cat $^ | sed -e 's/.*CONFIG_VERSION_SIGN | 19:45 |
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:11 |
tgardner | smb, otp, back in a sec | 20:13 |
tgardner | smb, http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/59f097ef181b | 20:17 |
bdmurray | JFo: wrt to this kernel bug handling work item its just reviewing the existing kernel team debugging procedures right? | 20:31 |
bdmurray | JFo: the one assigned to me | 20:32 |
JFo | hmmmm, let me look | 20:33 |
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:34 |
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:35 |
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:36 |
kamal | make that: https://wiki.ubuntu.com/Kernel/KernelBootParameters | 20:37 |
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:38 |
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:39 |
JFo | thank you sir | 20:40 |
soren | How do I see what a given file looked like at a given revision with git? | 21:55 |
RAOF | I *think* git show $SHA:path/to/file works | 21:57 |
=== sconklin is now known as sconklin-gone | ||
=== bjf is now known as bjf[afk] |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!