| apw | Ng, we were missing some modules i believe in the older kernels whcih would have affected installation, try a daily around now, or beta-1 next week and see if its there | 09:10 |
|---|---|---|
| apw | RAOF, morning | 09:11 |
| apw | smb, i see stable is going mad: | 09:11 |
| apw | 144 queue-2.6.32/series | 09:11 |
| apw | 122 queue-2.6.33/series | 09:11 |
| smb | apw, Yeah, I am anciously looking forward to look over it | 09:11 |
| smb | apw, A lot of things all over the place on a first glance | 09:12 |
| apw | smb, i see those kvm patches are in there | 09:12 |
| apw | smb, or perhaps some of them, a few kvm patches anyhow | 09:13 |
| smb | apw, Not all | 09:13 |
| smb | Right | 09:13 |
| smb | Not the breaky one | 09:13 |
| smb | But this one has been fixed too | 09:13 |
| apw | oh yeah you must tell me about that, what the issue was, when you arn't busy | 09:14 |
| smb | apw, Oh, just grab a coffee | 09:15 |
| smb | :) | 09:15 |
| apw | RAOF, so whats your feeling on our drm backport? are we seeing generally better or the same reporting? | 09:20 |
| RAOF | apw: It's superb for nouveau. | 09:33 |
| RAOF | I don't think it's any worse than before :) | 09:34 |
| apw | RAOF, that is good input, thanks | 09:35 |
| === _ruben_ is now known as _ruben | ||
| Keybuk | huh | 14:21 |
| Keybuk | I/O has crept to a crawl here | 14:21 |
| Keybuk | dpkg is trying to unpack the linux kernel deb | 14:21 |
| Keybuk | and it's taken over an hour so far | 14:21 |
| === sconklin-gone is now known as sconklin | ||
| tgardner | Keybuk, this is a bad thing | 14:22 |
| chrisccoulson | Keybuk, i've noticed the same thing while doing some builds on my machine this morning | 14:23 |
| chrisccoulson | unpacking any deb at the moment is taking forever.... | 14:23 |
| chrisccoulson | i thought it might just be me though | 14:23 |
| tgardner | I've had the opposite experience. I think Lucid is much better at load leveling then Karmic. | 14:24 |
| Keybuk | tgardner: this is a new bug | 14:24 |
| Keybuk | first time I've ever seen it on lucid, and with 2.6.32-16 | 14:24 |
| Keybuk | sorry, this is the second time I've seen it | 14:24 |
| Keybuk | but both have been with -16 | 14:24 |
| tgardner | Keybuk, I sure don't see anything since -15 that have affected the I/O path | 14:25 |
| Keybuk | tgardner: it definitely isn't the scheduler | 14:26 |
| tgardner | ah, unless 'sched: Fix SMT scheduler regression...' | 14:26 |
| Keybuk | I/O scheduler anyway | 14:26 |
| Keybuk | cause I tried changing that to noop | 14:26 |
| tgardner | duo-core? try htop to see whats busy? | 14:27 |
| apw | Keybuk, on -16 and not on -15 ? | 14:27 |
| Keybuk | don't have htop | 14:27 |
| Keybuk | apw: I didn't see it on -15 | 14:28 |
| tgardner | I've been doing -j8 builds while listening to tunes and surfing. | 14:28 |
| Keybuk | but I didn't have -15 installed for long | 14:28 |
| Keybuk | tgardner: it seems to be writing to disk that gets incrementally slower? | 14:28 |
| * apw has been running -16 for some days longer than has been uploaded and not seen that | 14:28 | |
| tgardner | but an hour? thats ridiculous | 14:28 |
| tgardner | is it actually doing anything? | 14:29 |
| Keybuk | yes | 14:29 |
| Keybuk | writing 4096 bytes at a time | 14:29 |
| Keybuk | about one write a second | 14:29 |
| apw | Keybuk, what does top say we are doing | 14:30 |
| tgardner | can you write any other files whilst this is going on? | 14:30 |
| Keybuk | apw: top just says dpkg | 14:30 |
| Keybuk | in fact, top thinks dpkg is hardly using any CPU because it's entirely syscall | 14:30 |
| Keybuk | tgardner: yes, other writes seem fine | 14:30 |
| apw | percentage idle/wait etc ? | 14:30 |
| Keybuk | apw: dpkg appears always in D state | 14:31 |
| apw | well -15 -> -16 had drm33, apparmor update, and that SMT update | 14:32 |
| apw | drm sounds unlikely, apparmor is only open stuff as far as i know | 14:32 |
| chrisccoulson | Keybuk - i'm only noticing this issue with dpkg, and I'm also running karmic's kernel and still have the issue | 14:32 |
| Keybuk | huh | 14:32 |
| Keybuk | right, that just finished | 14:33 |
| tgardner | apw, SMT update? could be a semantic change | 14:33 |
| Keybuk | apt started a new dpkg run | 14:33 |
| Keybuk | and that dpkg is running just fine | 14:33 |
| apw | and the SMT update is supposed to be for core to core movment | 14:33 |
| * apw wonders about what chrisccoulson just said | 14:33 | |
| tgardner | apw, which is why I asked if Keybuk has a duo-core | 14:33 |
| apw | if its on karmic its unliekly a kernel issue me thinks | 14:33 |
| chrisccoulson | and this dpkg change (37 hours ago) might be a clue: | 14:33 |
| chrisccoulson | Call fsync(2) after writing files on disk, to get the atomicity | 14:33 |
| chrisccoulson | guarantees when doing rename(2). Based on a patch by Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com> | 14:33 |
| Keybuk | tgardner: two dual-core Althon 64s | 14:33 |
| apw | Keybuk, so he could be affected ... | 14:34 |
| Keybuk | chrisccoulson: this is slowness in writes alone - within single files :-/ | 14:34 |
| apw | tgardner, would an awoken but not picked up runnable show as D though | 14:34 |
| tgardner | uh, fiik | 14:35 |
| apw | chrisccoulson, can you test the same operation | 14:35 |
| apw | Keybuk, what op you doing exactly ... so i can try here | 14:35 |
| tgardner | smb is knowledgeable | 14:35 |
| apw | Keybuk, and what version of kernel and dpkg do you have | 14:35 |
| Keybuk | apw: dist-upgrade from wednesday to today | 14:35 |
| gnarl | tgardner, huh? what makes you think? | 14:35 |
| Keybuk | apw: don't know exact versions, because I'm mid upgrade :p | 14:36 |
| apw | Keybuk, so -16.25 kernel | 14:36 |
| tgardner | gnarl, 'cause you've dealt with I/O stuff in the past. | 14:36 |
| apw | and dpkg? | 14:36 |
| apw | Keybuk, what extract command line you using | 14:36 |
| apw | so i am testing the exact same thing | 14:36 |
| gnarl | tgardner, Heh, yeah in the past. And block layer. Not much help with filesystems | 14:37 |
| gnarl | But it sounds strange that only dpkg is slow | 14:37 |
| Keybuk | 2010-03-12 13:31:13 upgrade dpkg 1.15.5.6ubuntu1 1.15.5.6ubuntu2 | 14:37 |
| Keybuk | 2010-03-12 13:32:55 upgrade linux-image-2.6.32-16-generic 2.6.32-16.24 2.6.32-16.25 | 14:37 |
| Keybuk | so both dpkg and linux-image were upgraded in this run | 14:37 |
| Keybuk | I must be running 16.24 | 14:37 |
| chrisccoulson | maybe we have different issues, but dpkg is painfully slow on my machine even with 2.6.31 | 14:38 |
| apw | can you not cat /proc/version_signature for us? | 14:38 |
| Keybuk | Ubuntu 2.6.32-16.24-generic | 14:38 |
| Keybuk | apw: I didn't know about that ;) | 14:38 |
| apw | ok so its _not_ the SMT change as that is in .25 | 14:38 |
| Keybuk | maybe the SMT change fixes it? :p | 14:39 |
| apw | Keybuk, uname -a also has the same info hidden in it | 14:39 |
| apw | heheh | 14:39 |
| apw | maybe | 14:39 |
| tgardner | Keybuk, is it clipping right along now? you said it finished the one deb it was doing. | 14:39 |
| apw | though what you are doing is mostly singly threaded so i'd doubt it | 14:39 |
| Keybuk | yeah it's clipping along just fine now it's done that deb | 14:40 |
| Keybuk | apw: ah, no, dpkg usually spreads across two cores when it unpacks | 14:40 |
| tgardner | anything in dmesg indicating disk corruption? | 14:40 |
| Keybuk | one core reads the deb, the other writes to disk | 14:40 |
| Keybuk | tgardner: first thing I checked, nup | 14:40 |
| apw | Keybuk, and t'is still slow as snot? | 14:40 |
| Keybuk | apw: no, is fine now | 14:41 |
| Keybuk | was just that deb | 14:41 |
| apw | which deb? | 14:41 |
| Keybuk | ironically, the kernel image one ;) | 14:41 |
| apw | thats not even that big? | 14:41 |
| Keybuk | oh, and kernel headers probably | 14:41 |
| apw | headers is shit loads of files, an fsync after every single close would be bad performance wise | 14:41 |
| apw | so it would depend what this change in dpkg actually does | 14:42 |
| Keybuk | fsync() is supposed to be ok for ext4 no? | 14:42 |
| Keybuk | huh | 14:43 |
| apw | define ok. if i read this description right it does it after every rename | 14:43 |
| Keybuk | though saying that | 14:43 |
| Keybuk | dpkg was upgraded first | 14:43 |
| Keybuk | so that might have been done with new dpkg | 14:43 |
| apw | which would likely be after every single file written, write tmp file, rename in | 14:43 |
| Keybuk | yeah | 14:43 |
| Keybuk | it would be | 14:43 |
| apw | if it does that for small files, kiss your ass goodbye | 14:43 |
| apw | Keybuk, there are 11692 files in a linux-headers file ... an fsync after ever one of those would be ... bad | 14:44 |
| apw | sooo ... need to know where the fsync went | 14:45 |
| Keybuk | yes | 14:45 |
| Keybuk | I'm thinking you're right | 14:45 |
| apw | normally if dpkg is updated in an update, that gets applied first before all others right? | 14:45 |
| gnarl | On every extracted files it seems | 14:45 |
| gnarl | And on directories as well | 14:46 |
| smb | http://launchpadlibrarian.net/39182845/dpkg_1.15.5.6ubuntu2.debdiff | 14:46 |
| gnarl | apw, ^ | 14:47 |
| apw | gnarl, thanks ... Keybuk got the git commit over on #u-d | 14:47 |
| pgraner | tgardner: Hey jono tried that rfkill suggestion, no difference | 15:11 |
| tgardner | saw that. | 15:12 |
| pgraner | tgardner: I'd like to try and get to a root cause prior to you taking off next week | 15:12 |
| pgraner | tgardner: anything I can do to facilitate that? | 15:13 |
| tgardner | pgraner, I'm thinking that if an rfkill or 'modprobe -r' and 'modprobe' doesn't fix it, then its likely not a kernel issue. | 15:13 |
| apw | tgardner, looks like they did add an fsync per file in pkg, and they did it for good reasons due to ext4 semantics being at the loose end of whats allowed ... so ... ouch | 15:14 |
| apw | no the kernels fault directly | 15:14 |
| tgardner | do we have one of these 5K parts somewhere in a laptop? | 15:14 |
| tgardner | pgraner, ^^ | 15:14 |
| pgraner | tgardner: NM issue? | 15:14 |
| pgraner | tgardner: not that I know of, we can ask the hw lab | 15:14 |
| tgardner | pgraner, possibly, but its kind of the whipping boy for all connection failures. | 15:14 |
| pgraner | tgardner: any extra debug info we can get when it does crap out? | 15:15 |
| tgardner | pgraner, lemme get him to do the modprobe dance thing. | 15:15 |
| pgraner | tgardner: ack | 15:15 |
| cr3 | apw: I've been trying your suspend_test script in various combinations, one of which I find strange: 1. set acpi wake alarm; 2. run pm-hibernate; 3. pull the power plug out and immediately back in on a laptop without a battery. | 16:09 |
| cr3 | apw: oddly, the system doesn't resume after the wake alarm time, but works fine if I leave the power plug alone | 16:09 |
| tgardner | cr3, I doubt there is battery backed RAM on a laptop, 'cause there is already a battery. does this test really make sense? | 16:13 |
| cr3 | tgardner: I'm not sure I understand, this is for a hibernation rather than a suspend. does hibernation rely on ram? | 16:14 |
| tgardner | cr3, the ACPI alarm likely does | 16:15 |
| cr3 | tgardner: oh! I thought that was a cmos thing, makes sense then | 16:15 |
| tgardner | cr3, CMOS on a standard AT motherboard has a battery. Thats why your BIOS loses its brains if that battery goes dead. | 16:16 |
| cr3 | tgardner: but that has a separate battery on laptops, right? | 16:17 |
| tgardner | cr3, I think its likely the external battery in a laptop that serves that function, though I have to wonder why BIOS doesn't get scrambled when you pull the external battery. maybe I'm just all wet. | 16:19 |
| cr3 | tgardner: yeah, I was wondering the same thing (regarding pulling the battery, not regarding you being all wet... tmi) | 16:19 |
| jjohansen | laptop usually have a small battery or capacitor for the CMOS | 16:30 |
| jjohansen | I even have a laptop with a capacitor for the ram that gives me 2 min, to change the external battery during suspend | 16:31 |
| tgardner | jjohansen, makes sense | 16:32 |
| apw | cr3, you are relying on the EC to keep running without battery or mains, not sure that is reasonable | 16:40 |
| tgardner | apw, I think that dpkg change is _really_ slowing things down. | 16:46 |
| apw | its particularly painful for large packages like the kernel headers | 16:46 |
| tgardner | one of my mojo fast serves has been updating for over an hour. Karmic->Lucid usually takes about 20 minutes | 16:47 |
| apw | tgardner, pitti is asking questions in the MIR bug for ti-omap, which need answering before it can continue | 16:50 |
| tgardner | apw, do you have the bug number handy | 16:51 |
| tgardner | ? | 16:51 |
| tgardner | nm, found it | 16:51 |
| apw | not at the mo, google MIR ti-omap | 16:51 |
| apw | thats how i find it each time | 16:51 |
| tgardner | apw, responded. I should have looked first thing this morning. I get too dependent on my email filter to send me the right stuff at the right time. | 16:55 |
| apw | tgardner, actually i think i got them to 'no brainer' position. the general position of armel == 18month support only plus the fact i needs to be in main to get onto a CD ... means that its a slam dunk | 16:56 |
| tgardner | apw, yeah, its not like they'll cause regressions or interactions with other packages | 16:57 |
| cnd | tgardner: is that the normal process for a pre-stable patch? | 17:12 |
| tgardner | cnd, close enough. its all a bit ad-hoc. | 17:13 |
| cnd | k | 17:13 |
| tgardner | cnd, it depends on whether smb demands an SRU as well | 17:14 |
| cnd | ahh | 17:14 |
| cr3 | when I boot into the bios of a dell mini 10, the bios seems to indicate I'm not in supervisor mode. is there a way to get into the bios in supervisor mode? | 17:16 |
| tgardner | cr3, whatya mean? Is it passworded? | 17:17 |
| cr3 | tgardner: if it's passworded, I can't even find where to enter the password. it allows me to boot into the bios, with f2, but it's just that some features are greyed out with some caption saying that they are only available in "supervisor mode" | 17:18 |
| tgardner | cr3, maybe that equates to manufacturing mode? ask apw as he has one. | 17:18 |
| apw | hrm not sure i've ever notices | 17:19 |
| * apw reboots to find out | 17:19 | |
| cr3 | apw: in the boot menu, I see this caption on the right: All items on this menu cannot be modified in use rmode. If any items require changes, please consult your system Supervisor. | 17:20 |
| apw | cr3 do you have a security menu ? | 17:20 |
| apw | if so what is on there | 17:21 |
| apw | i have 'Supervisor Password is: Clear' | 17:21 |
| cr3 | apw: supervisor password is: clear; user password is: set | 17:21 |
| apw | User password is : clear | 17:21 |
| apw | on mine | 17:21 |
| apw | i think someone has added a password on it | 17:21 |
| apw | not normal i'd say | 17:21 |
| cr3 | crap, but I can't even find how to get prompted for that password, at least I could try "ubuntu" or somesuch | 17:21 |
| apw | there is a Set User Password just below | 17:22 |
| apw | but i'd say its not meant to have one | 17:22 |
| cr3 | apw: greyed out, not accessible using the arrow keys | 17:22 |
| apw | mine does not | 17:22 |
| apw | i'd say if the supervisor password is clear it'd not need one, but ... hrm | 17:23 |
| * cr3 considers either flashing the bios or opening up the darn thing to clear the cmos | 17:23 | |
| Keybuk | apw: OOOOOOH | 17:32 |
| apw | Keybuk, WHEEE | 17:32 |
| Keybuk | <insert Mary Whitehouse Experience Music> | 17:33 |
| Keybuk | apw: that was a reaction to your mincore() patch btw | 17:37 |
| apw | Keybuk, i thought it might be. hopeing you are out from under plymouth enough to test it for me | 17:37 |
| Keybuk | not yet | 17:38 |
| Keybuk | but shortly | 17:38 |
| clauden | hi kernelers | 22:47 |
| JFo | hi clauden | 22:48 |
| clauden | hi JFo | 22:48 |
| clauden | i seem to be digging myself into a hole trying to set up a diskless client with readonly filesystem... | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!