| === medberry is now known as med_out | ||
| === Quintasan_ is now known as Quintasan | ||
| smb | Morning +* | 07:38 |
|---|---|---|
| diwic | morning pqr s/p/s s/q/m /s/r/b | 07:39 |
| diwic | hmm, that will actually replace the r in morning as well | 07:39 |
| diwic | smb, anyway, I'm tracing down a 3.0 regression for a few HDAs and I believe I found the upstream commit that resolves the problem, but that patch is quite large. | 07:40 |
| diwic | smb, would you prefer a large upstream patch or something smaller that I crafted myself? | 07:41 |
| smb | diwic, From the point of view of a stable maintainer probably rather something crafted with the note why that was done. | 07:42 |
| smb | It is just better to decide what something does that way. It is a bit of a gap between rather preferring upstream vs. I can understand it... | 07:43 |
| diwic | smb, in this case I tend to agree | 07:44 |
| diwic | smb, you can search for commit 3af9ee6b83 for reference | 07:44 |
| diwic | should be in 3.1 | 07:45 |
| smb | diwic, Hm, yeah. Most of it looks not too bad actually. But the whole block in alc662_auto_fill_dac_nids looks a bit scary at least on the first glance | 07:47 |
| diwic | smb, yeah, it's mainly the stuff in alc_auto_look_for_dac I need here | 07:48 |
| diwic | smb, hmm, and actually that stuff is yet again rewritten in a later commit | 07:51 |
| diwic | smb, better craft something then probably | 07:51 |
| smb | diwic, It is always some tough decision. There have been bigger changes accepted in the past. Just then be prepared to get asked how well this was tested. It may make sense if you can say, there was just no other way to get this done and I did test it at least on the variety of hw I got that is affected. | 07:54 |
| smb | Unfortunately when larger changes were done, they usually _had_ some hidden pitfalls in certain cases in them as well. Which tends to lower the acceptance of big chances again. | 07:55 |
| diwic | smb, yeah, and tbh I'm a little afraid that would happen if we applied 3af9ee as is | 07:58 |
| smb | diwic, If even you are afraid, that is a bad sign. :) | 08:00 |
| jjohansen | gah! so I bisected my video problem, found the patch that broke it but, reverting it in newer kernels doesn't restore my display :( | 08:22 |
| jjohansen | just my luck | 08:22 |
| smb | Sounds like one of those days | 08:23 |
| jjohansen | yeah | 08:26 |
| smb | jjohansen, Still around? | 09:05 |
| jjohansen | yep | 09:05 |
| jjohansen | smb: ? | 09:06 |
| smb | jjohansen, I wonder whether you could have a peek at that sru Tim sent around (about igb). I have that is-the-stove-really-out nagging feeling about spinlock without any diabling | 09:06 |
| smb | If someone else would review and say it looks okish I just would ack it as well | 09:07 |
| jjohansen | smb: sure | 09:07 |
| jjohansen | urg, this is when I wish for my big monitor so I can run two instances of meld side by side | 09:14 |
| jjohansen | smb: your right about the is-the-stove-really-out nagging feeling, I have it too. I have the original up and this and am doing a full on proper comparison | 09:18 |
| jjohansen | and eval | 09:19 |
| smb | jjohansen, Ah ok. Yeah, somehow it feels to me that at least a spinlock_bh variant may be required | 09:20 |
| jjohansen | hrmmm, that is a frightening thought :) | 09:20 |
| smb | But its just that uneasy feeling I usually have about not turning off anything. Somehow I converted to use spinlock alone only if I had nesting... But that is maybe just overcautious | 09:21 |
| * jjohansen wishes the original patch hadn't crammed 4 or 5 different things into it | 09:21 | |
| jjohansen | of course but being overcautious is safe | 09:22 |
| smb | Exactly. Rather be safe than sorry and in the bug report I think was a version with irqsave and restore which has been dropped because the original patch did not use it. Though the original patch completely changed things... | 09:24 |
| jjohansen | well I am not so worried about what is done in the original patch as patches around it | 09:24 |
| jjohansen | the original didn't change things enough in the locking sense for that worry | 09:25 |
| smb | In that case I did not look that much on what was done upstream (taking the statement about it being complicated and not all needed to get the gist of what is needed). Mostly what is done looks ok (make the update happen all the time and lock on the callers). And also most callers seem to be things that are triggered from userspace only. Just the watchdog function I am not sure. And whether it may interrupt a caller from user-space in an unfor | 09:29 |
| smb | tunate way | 09:29 |
| smb | Still I did not want to get that patch forgotten just because I am a code worrier... :-P | 09:31 |
| jjohansen | smb: heh no worries, we will get it taken care of | 09:39 |
| jjohansen | smb: so this I am less than thrilled with the patch | 10:17 |
| smb | jjohansen, Oh, ok. So what are your worries there? | 10:18 |
| smb | (actually if you could just reply in the thread, then you'd have to type it only once..) | 10:19 |
| jjohansen | smb: in the context of locking _bh, or irq I think it is okay, but I am not entirely convinced the locking is doing much good | 10:19 |
| jjohansen | smb: basically, it does prevent similtaneous writers, but it does nothing for readers | 10:20 |
| smb | jjohansen, Ah, ok... Hm, missed that aspect then | 10:20 |
| jjohansen | smb: look at igb_get_stats in igb_main.c | 10:22 |
| smb | jjohansen, Probably did not look into all accesses. At least the hunks seemed to change read (in those cases) into a write (update) | 10:22 |
| jjohansen | in the original patch a copy is made after the update and the copy is what is returned to the readers | 10:22 |
| jjohansen | so they have a private copy | 10:22 |
| jjohansen | a snapshot | 10:22 |
| jjohansen | here we are returning the live structure | 10:23 |
| jjohansen | now the question is do we care? | 10:23 |
| jjohansen | the locking seems to have been mostly added for 64bit accesses on 32bit machines | 10:24 |
| smb | Hm, doing the snapshot ensures that the stats are coherent. I guess updates just happening more often would not be completely what is desired... | 10:24 |
| jjohansen | so right now I am trying to figure out if we care | 10:24 |
| jjohansen | if its only for consistency across 64 bit stats then we may not care | 10:25 |
| jjohansen | if its for snapshot consistency we do | 10:25 |
| smb | Well otoh locking sounds reasonable just because now there may be two readers causing parallel updates, won't they? | 10:25 |
| jjohansen | possibly, the writers certainly need locking of some form | 10:26 |
| jjohansen | but I am not familiar enough with the code to say if multiple writers can occur at that point | 10:26 |
| jjohansen | but the locking won't hurt | 10:26 |
| smb | iirc it was changing the code so reading the stats for example with ethtool woul update them at that time | 10:27 |
| smb | And I guess at least in theory that could happen in parallel | 10:27 |
| jjohansen | it really comes down to the readers | 10:27 |
| jjohansen | right | 10:28 |
| jjohansen | I think the writers can be parallel, I am just not positive | 10:28 |
| jjohansen | so, I good with the locking on the writer side | 10:28 |
| jjohansen | its the readers I am trying to figure | 10:29 |
| * jjohansen really wishes the original patch had been split up | 10:29 | |
| smb | Ok, let me have a look at this again in meld... | 10:29 |
| smb | wtf | 10:32 |
| smb | I am not sure why I care... There was a code warrior putting that into master-next already it seems... | 10:32 |
| jjohansen | o_O | 10:33 |
| smb | jjohansen, Just questioning my sanity: do you see it too? | 10:36 |
| jjohansen | hrmm, let me pull and see | 10:37 |
| jjohansen | ah gah my linux-next tree hasn't been updated to git hub | 10:39 |
| smb | oops | 10:41 |
| * smb -> lunch | 10:50 | |
| jjohansen | smb: so I don't believe we care. We aren't updating 64 bit values, and I don't see a reason for rx and tx stats to be a snapshot, that is if rx gets incremented while read tx it doesn't really matter | 11:02 |
| smb | jjohansen, Ah ok, so basically the net stats are not really verifyable the first place. If its only rx / tx then surely they are ok as long as the value itself is consistent | 11:04 |
| smb | Would be different when there was something like irqs as well which would or would not be consistent with rx or tx | 11:04 |
| jjohansen | well its a little more than rx or tx look in include/linux/netdevice.h for net_device_stats | 11:05 |
| jjohansen | eg you could get rx_bytes and rx_packets to be from different snapshots | 11:06 |
| jjohansen | but the lack of consistency there is a very minor problem | 11:07 |
| smb | Yeah, and probably was there before... | 11:07 |
| jjohansen | yep | 11:07 |
| mterry | ogasawara, hello! I'm just pinging you to make bug 849564 more visible. :) Very reproducable and pretty annoying regression. I'd be glad to help test kernels | 12:22 |
| ubot2 | Launchpad bug 849564 in linux "System76 Lemur: Does not suspend on second attempt" [Undecided,Confirmed] https://launchpad.net/bugs/849564 | 12:22 |
| apw | jjohansen, tyler hicks is the ecryptsfs man right ? | 12:24 |
| jjohansen | yep | 12:25 |
| jjohansen | I keep meaning to sit down with him but haven't yet | 12:25 |
| apw | jjohansen, heard any reports about encrypted swap corrupting stuff ? | 12:27 |
| * smb <- back | 12:27 | |
| apw | https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836 | 12:27 |
| ubot2 | Ubuntu bug 745836 in ecryptfs-utils "ecryptfs encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] | 12:27 |
| apw | smb, ^^ you may be interested in the bottom of this | 12:27 |
| apw | i assume swap actually is actually dmcrypt | 12:27 |
| kirkland | wow | 12:27 |
| jjohansen | apw: no | 12:27 |
| kirkland | apw: so swap is not encrypted using ecryptfs | 12:28 |
| kirkland | apw: it's just dmcrypt | 12:28 |
| smb | apw, Thought you were the bottom man... :-P | 12:28 |
| * smb looking | 12:28 | |
| apw | right ... i assume the users are confused | 12:28 |
| kirkland | apw: ecryptfs-setup-swap sets it up | 12:28 |
| kirkland | apw: you assume correctly, I think :-) | 12:29 |
| apw | smb, would you have time to poke this nest of worms ? | 12:30 |
| smb | apw, Not sure I really want to... | 12:31 |
| apw | jjohansen, if you do talk to tyler, tell him that people are reporting that the 'crap at the end of ecryptsfs files' bug is being reported not fixed even where the fixes are applied | 12:31 |
| apw | smb, heh now that i can understand :/ | 12:31 |
| apw | smb, i could swap you for working out why we have power problems if you like | 12:31 |
| jjohansen | apw: yeah, that is weird | 12:32 |
| smb | apw, I probably take the other land-mine then I guess | 12:32 |
| smb | apw, At least things exploding is more realistic | 12:33 |
| apw | smb, it sounds like they have a reproduce by in a vm if you scroll back a few comments | 12:37 |
| smb | Yeah. Will try the receipe and see what I get | 12:38 |
| Sweetshark | apw, smb: Hi there. | 13:04 |
| smb | Sweetshark, Hi, just reading through that bug | 13:05 |
| * Sweetshark is Bjoern Michaelsen. And yes, it seemed to be quite reproducable in the end. | 13:05 | |
| * smb Realized | 13:06 | |
| smb | Sweetshark, How small was the smal RAM? | 13:06 |
| smb | 512M? | 13:07 |
| * apw is suprised LO would start at all in that | 13:07 | |
| Sweetshark | smb: 512MB was enough here. | 13:08 |
| apw | Sweetshark, was it reproducible on oneiric ? | 13:08 |
| Sweetshark | and then open Firefox, imagesearch for large images and open 20 in tabs to make him swap. (Unless you kernelguys have something less pragmatic). | 13:09 |
| Sweetshark | apw: Havent tried yet. I just got it reproducable today. | 13:09 |
| * jjohansen -> waves good night | 13:09 | |
| smb | jjohansen, night | 13:09 |
| apw | Sweetshark, heh i think i'd probabally just boot the VM with less ram :) | 13:09 |
| apw | jjohansen, no bed bugs .... | 13:10 |
| smb | Also got some program done by someone to eat memory... Would try that too | 13:10 |
| === kentb-out is now known as kentb | ||
| === med_out is now known as medberry | ||
| Sweetshark | as for this affecting oneiric: it is highly likely as there are stacktraces for it: bug 854197 for example | 13:34 |
| ubot2 | Launchpad bug 854197 in libreoffice "soffice.bin crashed with SIGSEGV in QPaintEngine::drawImage() (dup-of: 745836)" [Undecided,Incomplete] https://launchpad.net/bugs/854197 | 13:34 |
| ubot2 | Launchpad bug 745836 in ecryptfs-utils "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836 | 13:34 |
| Sweetshark | or bug 801592 (which is closer to the original "cppu::throwException" stacktrace.) | 13:35 |
| Sweetshark | arggh, pasted the wrong bugs. | 13:36 |
| * Sweetshark better tries himself. | 13:38 | |
| smb | Sweetshark, I think at least the initial report of that was 32bit. Since you already spent quite a time with those, were there 64bit cases as well? | 13:41 |
| Sweetshark | smb: yes. | 13:43 |
| Sweetshark | smb: Actually I personally reproduced on natty 64-Bit. | 13:43 |
| smb | Ah good. So that does not matter | 13:44 |
| * ogasawara back in 20 | 14:16 | |
| tyhicks | apw, kirkland, Sweetshark: I looked into bug 745836 last night and have a gut feeling that it is an inode race condition that I fixed recently. I haven't had a chance to update the bug with my findings yet. | 14:19 |
| ubot2 | Launchpad bug 745836 in ecryptfs-utils "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836 | 14:19 |
| tyhicks | I started to backport the patches last night but ran out of steam | 14:20 |
| tyhicks | I think I've just got one left to do | 14:20 |
| smb | tyhicks, Just wondering, if it is encrypted home/swap it is dm-crypt no ecryptfs... | 14:21 |
| apw | tyhicks, though they claim near the bottom that removing ecryptfs from the equasion and the problem is still there | 14:21 |
| * tyhicks missed that | 14:22 | |
| apw | tyhicks, Sweetshark it was you who claimed to have tested with just dmcrypt swap and normal home right ? | 14:22 |
| tyhicks | I can reproduce this easily in my vm... let me give it a shot on an unencrypted home | 14:23 |
| apw | tyhicks, thanks | 14:23 |
| smb | tyhicks, or just replace the swap by an unencrypted one | 14:24 |
| tyhicks | apw smb: I couldn't reproduce it with encrypted swap and unencrypted home | 14:35 |
| tyhicks | smb: you wanted me to test unencrypted home with unencrypted swap? | 14:35 |
| smb | tyhicks, Interesting, in the bug report it is claimed with encrypted home and without encrypted swap it cannot be reproduced either... | 14:37 |
| smb | tyhicks, I am still installing a vm, so if you want to go for a try, sure | 14:37 |
| tyhicks | smb: I'm thinking that this is the eCryptfs inode race condition that I fixed upstream recently | 14:37 |
| tyhicks | smb: encrypted swap could add just enough latency into everything that the race condition exposes itself more often | 14:38 |
| smb | Ah, that may well be | 14:38 |
| smb | tyhicks, So since you were already quite close to have the patches ready (and probably a test kernel too), I think the best approch would be to give those a try first | 14:39 |
| tyhicks | smb: Ah, I just noticed that the fixes I had started backporting are already in oneiric | 14:44 |
| tyhicks | smb: Sweetshark says that it is highly likely that oneiric is affected, too, but I'm not seeing any reports against oneiric | 14:46 |
| smb | tyhicks, Sweetshark thought there were bug reports for oneiric too. But then said something about wrong ones and I am not sure with what kernel version those would have been opened anyway | 14:46 |
| Sweetshark | smb: I just got a vanilla oneiric beta2 vm ready. Trying to reproduce. | 14:47 |
| tyhicks | Sweetshark: great - that would give me a good idea about whether or not this patchset I'm backporting is going to fix it | 14:48 |
| smb | Sweetshark, tyhicks Can I let the two of you check into this. It feels like tyhicks has the best lead for the fix anyways | 14:48 |
| tyhicks | smb: works for me | 14:48 |
| tyhicks | smb: if I determine that eCryptfs is not at fault, I'll let you nkow | 14:49 |
| smb | Thanks a bunch. Yes, sounds good | 14:49 |
| * apw idly notes that 'thanks a bunch' is normally negative | 14:49 | |
| smb | oops | 14:50 |
| * smb meant it the positive way | 14:50 | |
| apw | thanks a lot! is normally possiblem t | 14:50 |
| apw | possible, thanks a lot. is often not :) | 14:50 |
| apw | isn't english great | 14:50 |
| * smb probably has to live with every second word he says is an insult, about drinking or sex without knowing | 14:51 | |
| Sweetshark | tyhicks: NOT reporoducable in oneiric beta2 with encrypted home and swap (or at least not easily reproducable). | 14:55 |
| tyhicks | Sweetshark: woohoo... I think I might be on the right rack | 14:56 |
| tyhicks | s/rack/track/ | 14:56 |
| tyhicks | Sweetshark: thank you! | 14:56 |
| Sweetshark | of course tests cant prove the absense of bugs ;) | 14:58 |
| tyhicks | Oh, I should probably get some quick confirmation on the natty kernel source that I'm using (I've never worked directly on an ubuntu kernel before now) | 15:04 |
| tyhicks | Is the master branch of git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git what I should be backporting against? | 15:05 |
| tgardner | tyhicks, either master or master-next | 15:07 |
| tgardner | master-next is the branch we'll actually apply the SRU patch agains | 15:08 |
| Sweetshark | tyhicks: what are the chances that Libreoffice itself is at fault here? I assumed pretty slim and closed as invalid. Since you have a idea what the root cause it do you agree that this is valid to assume? | 15:12 |
| tyhicks | Sweetshark: Tough to say just yet | 15:17 |
| Sweetshark | tyhicks: k | 15:17 |
| Sweetshark | well, if you find anything fishy from LO on this please reopen on libreoffice. | 15:18 |
| tyhicks | Sweetshark: at first glance, my reaction was "Oh, eCryptfs is doing something non-POSIX-like and libreoffice should maybe handle that better" but then as I looked into it more, I got the feeling that eCryptfs is at fault | 15:18 |
| Sweetshark | tyhicks: k thx | 15:19 |
| apw | ogasawara, the binary package is: linux-image-extra-3.0.0-9-virtual | 15:20 |
| apw | as an example from my test builds | 15:20 |
| ogasawara | apw: cool, was just about to check | 15:20 |
| ogasawara | apw: so we're fine there | 15:20 |
| apw | the theory behind the packaging changes is that you could pick any subset as a separate package | 15:20 |
| apw | so you could pull out staging for example | 15:21 |
| apw | though we don't do it | 15:21 |
| apw | bug #818177 | 15:21 |
| ubot2 | Launchpad bug 818177 in udev "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177 | 15:21 |
| * smb drops off | 15:32 | |
| sforshee | mjg59, do you know of any way to get a trace of the AML method calls being made by a driver under Windows? | 15:49 |
| mjg59 | sforshee: Nope | 15:49 |
| sforshee | rats | 15:49 |
| cking | sforshee, ask alexhung | 16:44 |
| cking | mjg59, nice response to microsoft's fluff | 16:46 |
| mjg59 | cking: Thanks! | 16:47 |
| sforshee | cking, already have, but I'm exploring a couple of alternate avenues | 16:47 |
| cking | I'm glad it's getting a whole load of attention | 16:47 |
| cking | sforshee, pity you can't slap in systemtap eh? | 16:48 |
| sforshee | cking, I found some kind of sample for tracing ioctls (which is how AML methods appear to be invoked on windows) | 16:48 |
| sforshee | heh | 16:48 |
| sforshee | cking, windows also seems to have support for something called filter drivers, which I think can be placed transparently between a driver and the hardware | 16:49 |
| cking | sforshee, that's interesting to know, so is the windbg approach a dead end? | 16:49 |
| sforshee | cking, it looked like it required some special hardware, so I'm looking at software-only solutions first | 16:50 |
| cking | sforshee, you could hack out the DSTD, put in some extra AML to do port 0x80 writes and then boot the machine with BITS to pre-load the tables into memory - and then chain boot Windows. | 16:51 |
| cking | you need a port 0x80 debug card ;-) and patience | 16:51 |
| cking | oh, SIGCHILD, gotta to attend my kids.. | 16:52 |
| sforshee | cking, that's an interesting idea, but these are netbooks so installing a port 0x80 debug card is going to be problematic :) | 16:52 |
| cking | sforshee, yep, I've always found they don't work well | 16:52 |
| cking | the mini PCI-e one's have never worked for me | 16:53 |
| mjg59 | sforshee: Alternative is to figure out where ACPI debug statements go on Windows and fill the AML with a pile of them | 16:53 |
| sforshee | mjg59, thanks, I'll look into that as well | 16:54 |
| * sforshee -> dr appt | 17:29 | |
| * tgardner -> lunch | 17:51 | |
| * apw calls it beer time, laters | 17:54 | |
| cjwatson | Hmm. Is there a reason why xenbus_probe_frontend is modular in several of our configs? | 18:12 |
| cjwatson | It means that other Xen drivers (e.g. xen-netfront) don't get autoloaded | 18:12 |
| cking | sforshee, be sure to write up your findings once you've figured out a workable methodology ;-) | 18:19 |
| tgardner | cjwatson, I think the backends are built-in for DomU clients. Aren't the front-end drivers for Dom0 ? or do I have it backwards. | 18:20 |
| * ogasawara lunch | 18:28 | |
| === _ruben_ is now known as _ruben | ||
| cjwatson | tgardner: I think you have it backwards | 18:41 |
| cjwatson | tgardner: I'm on a domU client at the moment - loading xenbus_probe_frontend is enough for it to find its network interface | 18:42 |
| cjwatson | and without that, the installer fails due to having no network interfaces; I could work around this in the installer, but it seems more correct to build this in unless there's a reason not to | 18:43 |
| cjwatson | tgardner: I've filed bug 857662 with a more complete rationale | 19:05 |
| ubot2 | Launchpad bug 857662 in linux "Should xenbus_probe_frontend be built-in?" [Undecided,New] https://launchpad.net/bugs/857662 | 19:05 |
| tgardner | cjwatson, ack | 19:05 |
| tgardner | cjwatson, are you using the server or virtual ? | 19:06 |
| cjwatson | explained in the bug | 19:06 |
| cjwatson | ... and corrected the description to match reality | 19:09 |
| tgardner | cjwatson, so you think CONFIG_XEN_XENBUS_FRONTEND=y will solve all your problems ? -virtual works as desired ? | 19:11 |
| cjwatson | I have no remotely straightforward way of trying -virtual - I don't control the host | 19:12 |
| cjwatson | I have tested that 'modprobe xenbus_probe_frontend' makes everything work | 19:12 |
| tgardner | cjwatson, ok | 19:13 |
| cjwatson | and I guess I sort of feel that -generic should be a superset of -virtual, normally? at least for "does it work"-ness | 19:13 |
| cjwatson | ISTR -virtual originally being just a make-it-smaller flavour | 19:14 |
| tgardner | cjwatson, actually, -server and -virtual are much more closely related (in amd64) | 19:14 |
| cjwatson | oh, is the -virtual config generated somehow? | 19:15 |
| cjwatson | I noticed | 19:16 |
| cjwatson | debian.master/config/amd64/config.flavour.generic:21:CONFIG_XEN_XENBUS_FRONTEND=m | 19:16 |
| cjwatson | debian.master/config/amd64/config.flavour.virtual:21:CONFIG_XEN_XENBUS_FRONTEND=y | 19:16 |
| cjwatson | and inferred that it wasn't a simple subset any more | 19:16 |
| tgardner | cjwatson, it was originally based on -server | 19:16 |
| * jjohansen -> lunch | 19:16 | |
| cjwatson | oh, I see, well, -server has CONFIG_XEN_XENBUS_FRONTEND=m too | 19:16 |
| cjwatson | I wouldn't object to switching the xen images over to -virtual in P if it's the kernel team's opinion that that would work better | 19:16 |
| cjwatson | and if you think CONFIG_XEN_XENBUS_FRONTEND=y across the board is too risky for Oneiric then I can add workarounds | 19:17 |
| tgardner | cjwatson, we tailored -virtual for use in xen environments | 19:17 |
| cjwatson | but I thought it made sense to ask first | 19:17 |
| tgardner | I'm still evaluating CONFIG_XEN_XENBUS_FRONTEND=y across the board | 19:17 |
| tgardner | its likely OK | 19:17 |
| tgardner | cjwatson, it _looks_ ok, but I think I've gotta test it on some bare metal first. | 19:22 |
| ogasawara | tgardner: lemme know how the tests go. I'll hold off on the upload for a bit so we can add the config change. | 19:25 |
| tgardner | ogasawara, it'll take 30 mins or so | 19:26 |
| ogasawara | tgardner: ack | 19:26 |
| tgardner | cjwatson, ogasawara: the only way to build in XEN_XENBUS_FRONTEND is by enabling one of the front end device drivers, e.g., CONFIG_XEN_BLKDEV_FRONTEND=y or CONFIG_XEN_NETDEV_FRONTEND=y. This is the reason we only enabled those drivers for -virtual. | 19:34 |
| tgardner | I'll add my rationale to the bug | 19:35 |
| cjwatson | tgardner: oh, drat | 19:51 |
| cjwatson | that seems like a bug in the upstream config system | 19:52 |
| cjwatson | since you can never get autoloading that way | 19:52 |
| tgardner | cjwatson, Im not saying it _won't_ work, I'm just a little reluctant at this late stage. | 19:52 |
| cjwatson | yeah, understood | 19:53 |
| cjwatson | switching to -virtual will be fine for P, and I'll work around it in the installer for Natty/Oneiric | 19:53 |
| tgardner | cjwatson, cool, much appreciated. | 19:54 |
| cjwatson | solutions that don't involve kernel changes are fine, I just have a little Keybuk voice in the back of my head going "we should just change the kernel" sometimes ;-) | 19:55 |
| tgardner | I guess I'm the anti-keybuk | 19:55 |
| tgardner | ogasawara, fire away | 19:55 |
| ogasawara | tgardner: I'm firing up test boots and will then pull the trigger | 19:56 |
| * tgardner -> EOW | 20:36 | |
| bryceh | ogasawara, heya | 21:18 |
| ogasawara | bryceh: hi what's up | 21:18 |
| bryceh | ogasawara, I want to build a kernel for a bug reporter to test, with an upstream patch applied | 21:18 |
| ogasawara | bryceh: want me to build it for ya? | 21:19 |
| bryceh | ogasawara, oh that'd be great | 21:19 |
| ogasawara | bryceh: sure, just point me to the patch. | 21:19 |
| bryceh | it's comment #7 on https://bugs.freedesktop.org/show_bug.cgi?id=41059 | 21:19 |
| ogasawara | bryceh: I assume oneiric kernel? and do they need amd64 or i386? | 21:19 |
| ubot2 | Freedesktop bug 41059 in Driver/intel "XRANDR operations very slow unless (phantom) HDMI1 disabled" [Major,New] | 21:19 |
| bryceh | ogasawara, amd64 | 21:20 |
| ogasawara | bryceh: once I've got it, you want me to just post the url to the test kernel in that bug? | 21:21 |
| bryceh | ogasawara, yep that'd be perfect | 21:21 |
| ogasawara | bryceh: ack, will do | 21:21 |
| bryceh | thanks ogasawara! | 21:23 |
| htorque | bryceh: hi! what do you say - are 120 ms per DP port probe ok? HDMI2 and HDMI3 in comparison are much faster. | 21:25 |
| bryceh | htorque, keith packard's been reworking the DP probing code lately | 21:30 |
| bryceh | we've seen some horrible times, particularly eDP, of 500-1000ms in some cases | 21:31 |
| bryceh | so compared with that 120 ms doesn't seem too bad | 21:31 |
| bryceh | however my expectation would be that it should be much lower than that | 21:31 |
| htorque | bryceh: okay, thanks for your answer! :) | 21:32 |
| bryceh | Given the recent trend of hardware with lots of different ports, what concerns me is the sum of doing these probes in serial. I wonder why they're not done in parallel; is that even possible? | 21:32 |
| bryceh | htorque, keithp has a code branch with reworked DP probing that we had a couple people test and they found it significantly imprved boot speed | 21:33 |
| bryceh | I've communicated this to Intel, which they were glad to hear and hopefully they'll have that new code finished, QA'd, and available in time for LTS | 21:34 |
| bryceh | I am not confident it's something we'd want to risk SRUing for oneiric but guess we can decide at some point when the code is ready | 21:34 |
| htorque | bryceh: the 1.6 sec. from HDMI1 are definitely worse - especially if you don't have HDMI ports :P | 21:35 |
| htorque | do you have a link to that branch? | 21:35 |
| bryceh | no but I can dig it up, one sec | 21:37 |
| htorque | bryceh: found this: http://kernel.ubuntu.com/~sarvatt/macbook-air/ | 21:37 |
| bryceh | aha yeah that's it | 21:38 |
| htorque | bryceh: from 120 ms per port to 50 ms per port. nice! :) | 21:44 |
| bryceh | htorque, most excellent :-) | 21:47 |
| === kentb is now known as kentb-out | ||
| === kamalmostafa is now known as kamal | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!