| === smb` is now known as smb | ||
| smb | morning .* | 07:46 |
|---|---|---|
| cooloney | smb and cking, good morning | 07:59 |
| * cking waves to cooloney | 07:59 | |
| smb | hey cooloney | 07:59 |
| === henrix_ is now known as henrix | ||
| * apw groans | 08:17 | |
| cking | too little coffee apw? | 08:17 |
| cooloney | apw: morning coffee is good for you | 08:18 |
| ppisati | cooloney: i heard Apple stocks skyrocketed after the news :) | 08:21 |
| ppisati | brb | 08:35 |
| tjaalton | anyone able to confirm that the ubuntu-r kernel oopses 0.2 seconds into the boot? mainline works fine, but I'm unable to see the origin of the oops.. | 08:36 |
| cooloney | ppisati: hey, man, what news? | 08:41 |
| ppisati | tjaalton: did you try with earlyprintk? | 09:05 |
| tjaalton | ppisati: ah, no I didn't | 09:06 |
| tjaalton | don't have the hw though :) | 09:06 |
| tjaalton | the oops does show on the screen, but it goes past so fast that it's useless | 09:07 |
| tjaalton | the tail isn't that interesting I think | 09:07 |
| juergh | apw Do you know where I can find the headers and ddebs for the aa test kernel that you guys built on Tuesday? | 09:18 |
| === AndChat|665849 is now known as arges-trai | ||
| === arges-trai is now known as arges-train | ||
| * ppisati -> out for lunch | 10:33 | |
| cking | henrix, http://people.canonical.com/~kernel/reports/sru-report.html - bugs 561129 and 1047261 don't have the needs verification tags on these yet. is that an automated process? | 10:50 |
| ubot2 | Launchpad bug 561129 in ecryptfs "Existing eCryptfs inodes are not evicted when they're the target of a rename()/mv" [Medium,Fix released] https://launchpad.net/bugs/561129 | 10:50 |
| ubot2 | Launchpad bug 1047261 in ecryptfs "ecryptfs_encrypt_page: Error attempting to write lower page (regression)" [High,Fix released] https://launchpad.net/bugs/1047261 | 10:50 |
| henrix | cking: no, it's a manual process. | 10:51 |
| henrix | cking: "officially" we're not on the verification week yet :) | 10:51 |
| cking | oh, I've verified them too early then ;-) | 10:52 |
| * cking fail, too efficient | 10:52 | |
| henrix | cking: heh | 10:52 |
| henrix | but i'll be adding those tags to some of the kernels later today, as we're pretty much done with the prep phase :) | 10:52 |
| henrix | btw, if you've already verified these bugs, you can add the verification-done-... tag | 10:54 |
| henrix | the bot will pick these tags once it updates the report | 10:55 |
| henrix | cking: ah, i see you've already commented the bugs with the test results | 10:59 |
| henrix | cking: so, don't worry about them anymore. i'll tag them. thanks ;) | 10:59 |
| pocoporco | hello | 11:41 |
| phillw | hi guys, with respect to bug 1043518 there is a working patch in place via https://bugzilla.redhat.com/show_bug.cgi?id=857300 but that is absolute limit of my scant knowledge of the inner workings of kernels. Could someone take a look and see if it can be added to our 3.5.x kernel? Thanks. | 11:57 |
| ubot2 | Launchpad bug 1043518 in plymouth "live cd is unusable due to video degradation with the splash boot option enabled" [Undecided,Invalid] https://launchpad.net/bugs/1043518 | 11:57 |
| ubot2 | phillw: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found (https://bugzilla.redhat.com/xml.cgi?id=857300) | 11:57 |
| === zz_Kiall is now known as Kiall | ||
| * henrix -> SIGFOOD | 12:06 | |
| === Kiall is now known as zz_Kiall | ||
| henrix | rtg: regarding bug #1039157, a fix as been applied to the lucid kernel | 12:39 |
| ubot2 | Launchpad bug 1039157 in linux "vmware/virtualbox kernel modules not loaded by default" [Undecided,Fix committed] https://launchpad.net/bugs/1039157 | 12:39 |
| henrix | rtg: however, i believe this fix shouldn't have been applied, as vmwgfx driver is not build | 12:39 |
| henrix | its obviously an harmless fix, but there's no way to verify the bug :) | 12:40 |
| rtg | henrix, hmm | 12:40 |
| rtg | henrix, well, I guess its harmless and not too difficult to verify. | 12:43 |
| rtg | oh, you already said that :) | 12:43 |
| henrix | rtg: i say "harmless", but not easy to verify... | 12:44 |
| henrix | rtg: since the code is not compiled, i can only confirm it is *not* compiled | 12:44 |
| rtg | henrix, well, revert it then. | 12:45 |
| henrix | rtg: ack, thanks | 12:45 |
| === doko_ is now known as doko | ||
| rtg | ppisati, you should rebase ti-omap4 to pick up the AA stack patch. | 13:18 |
| ppisati | rtg: i'll do | 13:48 |
| rtg | ppisati, thanks | 13:49 |
| ppisati | rtg: i915 stuff? actually it's useless here, but i'll do a rebase anyway | 13:50 |
| rtg | ppisati, I don't care about that stuff, but the AppArmor patch definitely has an impact on ARM | 13:51 |
| ppisati | i don't see it | 13:51 |
| ppisati | master-next maybe? | 13:51 |
| rtg | on master-next ? | 13:51 |
| rtg | ppisati, oh, right. perhaps you should wait until master is uploaded again. | 13:51 |
| ppisati | right | 13:52 |
| rtg | piidoh! got ahead of myself | 13:52 |
| === zz_Kiall is now known as Kiall | ||
| ppisati | i've all stable kernels to do, i'll queue it too | 13:52 |
| rtg | ppisati, ok, I'll nag you again _after_ ogasawara uploads... | 13:53 |
| ogasawara | ppisati: I was planning on uploading this afternoon. So you can probably expect to rebase on a new master tomorrow morning for you. | 13:55 |
| ppisati | ack | 13:58 |
| jsalisbury | rtg, upstream responded on bug 1045027 . They are working on a fix, but if they can't find one, they will revert b398aa31 in 3.5. Should we revert b398aa31 since we know it fixes the bug, and we don't know how long upstream will take? | 14:13 |
| ubot2 | Launchpad bug 1045027 in linux "[regression] iPXE kills kvm with KVM: entry failed, hardware error 0x80000021" [Critical,In progress] https://launchpad.net/bugs/1045027 | 14:13 |
| rtg | jsalisbury, I saw that. I think we should revert that patch in the meantime 'cause I doubt they'll come up with a workable solution anytime soon. | 14:13 |
| jsalisbury | rtg, ok, thanks. I can submit a revert request to the kernel-team mailing list. | 14:14 |
| rtg | jsalisbury, please do. | 14:14 |
| jsalisbury | rtg, sent | 14:27 |
| sforshee | bjf, I've got some test kernels for your wireless issue I'd like you to try out. There will still be performance issues, but they should get rid of the "no where to go" errors. | 14:36 |
| sforshee | bjf, http://people.canonical.com/~sforshee/lp1046507/ | 14:36 |
| sforshee | bjf, if you aren't using amd64 let me know and I'll build i386 packages | 14:37 |
| bjf | sforshee: i'm using amd64, will give it a spin | 14:38 |
| sforshee | bjf, thanks | 14:38 |
| bjf | sforshee: no, thank _you_. this is the system i'm taking to uds and i'd really like the wireless to work :-) | 14:38 |
| sforshee | bjf, with the iperf tests I still get complete stalls of network performance sometimes. I think some of the periodic drops in performance might be related to something going wrong during background scans. | 14:39 |
| rtg | who ever thought back ground scans were a good idea ? | 14:40 |
| rtg | especially on a half duplex radio | 14:40 |
| bjf | sforshee: this is a 3.6-rc7 based kernel ? | 14:41 |
| sforshee | bjf, also you'll see a lot of messages about now space in the fifo and prep_xdu retries. Those should be harmless, I'll probably add a patch to demote those to debug-only | 14:41 |
| sforshee | bjf, yes, it's based off of the wireless-testing tree | 14:41 |
| sforshee | rtg, it seems like brcmsmac may be loosing some packets on rx during scans. I haven't dug into it yet, may be a problem with ps-poll. | 14:42 |
| rtg | sforshee, ps-poll should be easy enough to verify. just turn it off ? | 14:43 |
| sforshee | rtg, I need to look closer at what happens when we go off-channel. My assumption is that we send a ps-poll frame to the AP so it will queue up frames until we come back, but I'm not sure if that's the case. If that's what's happening and we turn of ps-poll wouldn't we loose all packets during the scan? | 14:45 |
| rtg | sforshee, IIRC the client can only send ps-poll requests. lemme check the spec. | 14:46 |
| sforshee | rtg, I'm a little confused about the names of things it seems. ps-poll is what the sta sends to retrieve frames queued by the AP. | 14:48 |
| sforshee | anyway, I'm going to look into it, just haven't gotten to it yet | 14:49 |
| bjf | sforshee: i've got it running, will let you know more in a bit | 14:49 |
| rtg | sforshee, correct. now that I think about it using ps-poll makes sense if the STA is going off channel. the AP shouldn't send and directed packaets to a STA that has not submitted a ps-poll request. | 14:49 |
| rtg | of course, the AP if free to drop any queued packets after awhile if the STA doesn't get around to sending a ps-poll request | 14:50 |
| sforshee | rtg, right | 14:51 |
| rtg | sforshee, also, PS-POLL was an optional feature in the original spec. I believe it was negotiated during the association phase. | 14:55 |
| sforshee | rtg, I think you're right about it being negotiated | 14:57 |
| phillw | cking: do you think bug 1056885 is a mis named dupe of bug 1043518 (nvidea = no plymouth)? | 15:01 |
| ubot2 | Launchpad bug 1056885 in xserver-xorg-video-nouveau "Screen shows corruption on LiveCD/installer" [Undecided,New] https://launchpad.net/bugs/1056885 | 15:01 |
| ubot2 | Launchpad bug 1043518 in linux "live cd is unusable due to video degradation with the splash boot option enabled" [High,Fix committed] https://launchpad.net/bugs/1043518 | 15:01 |
| * cking looks | 15:01 | |
| cking | phillw, most probably | 15:02 |
| phillw | I'll mark it as a dupe, with a comment for the OP. Thanks, | 15:02 |
| bjf | sforshee, just using it for normal things (not running iperf) it seems to be behaving much better | 15:03 |
| sforshee | bjf, good | 15:04 |
| ogasawara | ppisati: I'm told there is "some kernel bug" blocking automated arm testing. Any idea what that bug# is? | 15:12 |
| ppisati | ogasawara: yes, and it's not a bug | 15:13 |
| ppisati | ogasawara: i told me so many times | 15:13 |
| ogra_ | you talk to yurself about bugs ? | 15:13 |
| ppisati | ogasawara: there's an automated test that compiles another program to read memory location | 15:13 |
| ppisati | no i answered in the bug | 15:13 |
| ppisati | ogasawara: and they need the kernel headers installed | 15:13 |
| ogasawara | pgraner, slangasek: ^^ | 15:14 |
| ppisati | on my laptop qemu -redirect works, on my dekstop it doesn't uhm... using the network stack | 15:18 |
| ppisati | any idea? | 15:18 |
| ogra_ | same versions ? | 15:19 |
| ppisati | yep | 15:21 |
| ppisati | it's driving me crazy | 15:21 |
| ogra_ | both wired lan ? | 15:22 |
| ppisati | ogra_: well, i'm using the qemu user netqwork stack | 15:31 |
| ppisati | and -redirect-ing a localhost port to guest port (22) | 15:31 |
| ppisati | it shouldn | 15:31 |
| ppisati | t involve anything sicne it's all done in userspace | 15:31 |
| ppisati | but for some reason my setup works on my laptop | 15:31 |
| ppisati | and it fails on my desktop | 15:31 |
| ppisati | frrr... | 15:32 |
| ppisati | grrr... | 15:32 |
| ppisati | <frrr sounds like i'm purring> | 15:32 |
| slangasek | ogasawara, ppisati: ok, sounds like this bug is in hggdh's hands, thanks | 15:32 |
| ogra_ | well, there sholudnt be a difference but there might be between NM managed devices and /etc/network/interfaces ones | 15:32 |
| ogra_ | for example | 15:32 |
| ogra_ | so i would inspect the differences between your desktop and laptop | 15:32 |
| ogra_ | (systemic ones) | 15:33 |
| ppisati | ogra_: didn't think about NM, good idea | 15:34 |
| ogra_ | ppisati, oh, and silly question, is anything on the host already claiming the port perhaps ? | 15:40 |
| * ogasawara bails to pick up new router. back in 30 | 16:03 | |
| doko | rtg, ogasawara: would like to coordinate with kernel/gcc uploads after the freeze | 16:09 |
| doko | these versions are found in the ubuntu-toolchain-r repo, and used for the current test rebuild. no code changing changes | 16:10 |
| doko | had a local kernel build, which works fine for me | 16:10 |
| ppisati | lp 1027524 | 16:24 |
| ubot2 | Launchpad bug 1027524 in linux-ti-omap4 "QRT failed on test_072_config_debug_rodata and test_072_strict_devmem" [Medium,Confirmed] https://launchpad.net/bugs/1027524 | 16:25 |
| ppisati | i just reran the test manually, and i added result and the step-to-step cmds that i ran | 16:25 |
| ppisati | test_072_strict_devmem (__main__.KernelSecurityTest) | 16:25 |
| ppisati | /dev/mem unreadable for kernel memory ... (using 0xa9d6b640L) (exit code 0) ok | 16:25 |
| ppisati | ogasawara: pgraner: slangasek: ^ | 16:25 |
| rtg | doko, ogasawara was planning to upload later today. if there are no impacts on the kernel is there any reason to coordinate ? | 16:26 |
| ogasawara | bah, stupid best buy isn't open till 10am | 16:27 |
| rtg | bummer | 16:27 |
| ogasawara | doko: if there are impacts, could you just ping me when you upload. I'll hold off on our kernel upload till after I see gcc finishes. | 16:27 |
| ogasawara | ppisati: thanks | 16:28 |
| ppisati | how do i show the bzr revision i am on? | 16:29 |
| ppisati | bzr status? bzr info? bzr foobar? | 16:29 |
| ppisati | just to show bzr revision i used | 16:29 |
| doko | ogasawara, rtg: ok. then proposing to copy the binaries from the ppa, and then building the kernel once these are published | 16:29 |
| ogra_ | bzr log|head | 16:29 |
| rtg | doko, sounds good | 16:30 |
| doko | however I'll be away until 21:00 utc | 16:30 |
| slangasek | ppisati: hmm, the problems with this test look familiar to me | 16:37 |
| ppisati | slangasek: ??? | 16:38 |
| slangasek | ppisati: the /dev/mem thing | 16:39 |
| slangasek | ppisati: some of the portland locals have had extensive discussions about this test on ARM :) | 16:39 |
| ppisati | slangasek: any transcription anywhere? | 16:40 |
| slangasek | ppisati: no, I'm poking people now to get a current status dump | 16:40 |
| ppisati | slangasek: besides, today's tip of qa-regression-testing work ok | 16:41 |
| slangasek | ok | 16:43 |
| ppisati | flag@flag-desktop:~/qrt-test-kernel-security/kernel-security/mem$ sudo ./readmem 80008000-80846787 : Kernel code | 16:43 |
| ppisati | 0x80008000 ... good: EPERM | 16:43 |
| ppisati | case EPERM: | 16:43 |
| ppisati | // disallowed memory region! STRICT_MEM is working, exit 0 | 16:43 |
| ppisati | printf("good: EPERM\n"); | 16:43 |
| ppisati | return 0; | 16:43 |
| ppisati | from readmem.c | 16:43 |
| ppisati | i mean, more than this, i can't really do | 16:44 |
| ppisati | besides, these tests build some kernel modules to find and then insmod/rmmod these modules to find a suitable memory location | 16:45 |
| ppisati | that's why you need kernel and headers synced | 16:45 |
| * ppisati goes for a mildly alcholic aperitif | 16:53 | |
| * ppisati -> EOD | 17:01 | |
| edgecase | in file drivers/pnp/isapnp/core.c EXPORT_SYMBOL(isapnp_read_byte) got dropped from kernel, any idea how to use git to find out when? | 17:03 |
| rtg | edgecase, looks like commit 1e0aa9ad721349781b728ec4226876247e3fd431 | 17:16 |
| edgecase | thanks, i just found it in gitweb, manual bisect heh | 17:17 |
| edgecase | was "cleaned up" in 2005... i get the feeling my ISA GPIB card is obsolete | 17:17 |
| * henrix -> EOD | 17:41 | |
| * rtg -> lunch | 17:41 | |
| jgriffith | smb: ping again :) | 17:45 |
| * cking -> EOW | 17:54 | |
| === henrix is now known as henrix_ | ||
| === chronossc is now known as chronos | ||
| === yofel_ is now known as yofel | ||
| bjf | sforshee, that driver has finally given up. i just get the warning oops out of it now. anything you want me to do before i restart it? | 20:12 |
| sforshee | bjf, just grab dmesg and send it to me | 20:16 |
| * rtg -> EOD | 20:16 | |
| sforshee | bjf, when you were getting all of those warnings did you have heavy network activity on the machine? | 21:02 |
| bjf | sforshee, no, just tbird and was browsing to cnn.com | 21:05 |
| bjf | sforshee, i recognize something tipped it over, just wasn't doing anything special at the time that I can think would have done it | 21:06 |
| sforshee | bjf, okay. brcmsmac will queue a lot of data internally, and I suspect that sometimes when it goes to flush it just has too much data queued to send in the time it's giving the flush to complete. Hard to tell if that was the case for you. | 21:07 |
| sforshee | bjf, I don't see any of the "No where to go" messages though, which is what those patches are really meant to address. | 21:09 |
| bjf | sforshee, ack, i've not seem them either | 21:10 |
| sforshee | bjf, I'm going to keep working on the other issues. I've found that if I do iperf with UDP packets in either direction I can't trigger performance problems, except during scans. It seems doing lots of tx and rx simultaneously is most likely to cause it to bind up. | 21:13 |
| bjf | sforshee, ack | 21:14 |
| doko | ogasawara, rtg: binutils and gcc-4.7 should be available in quantal in about 30min | 22:15 |
| ogasawara | doko: ack, thanks | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!