[08:21]  * smb is now nearly past his first coffee
[08:34] <apw> smb, already so soon, you will be high as a kite
[08:35] <smb> apw, Nah, I can stop anytime I want... Really!
[08:35]  * smb starts cup #2
[08:37]  * apw looks jelous
[08:45] <smb> apw, I'd share if you would sit closer...
[08:45]  * apw puts the kettle on
[08:45] <apw> bah there is yet another pulse update in my queue ... sigh
[08:45] <bryce> apw, one week til FF, everyone's hurrying to finish breaking everything
[08:45] <apw> yeah, great fun this week is going to be
[08:45] <smb> go with the challenge
[08:46] <apw> 210M of updates for me today, i guess i misses yesterday on this machine ... thats what a full 1/4 of everything installed
[09:19] <smb> Must be related to Friday...
[10:07] <diwic> I'm trying the latest i386 live-cd on my (older) laptop, and I get the error message that it misses the "pae" feature.
[10:08] <diwic> Is there anything I can do to boot a Live-CD off this one, or is it just not supported anymore?
[11:42]  * ppisati -> out for lunch
[12:50] <apw> diwic, i suspect that that image is no good for you
[12:51] <diwic> apw, so assume I want to install precise on this laptop; which I'm currently IRCing from, btw.
[12:51] <diwic> apw, how would I do? Could I use the alternate install CD or is that also booting a pae kernel?
[12:52] <apw> diwic, you know i have no idea.  i would have to refer you to cjwatson on what cds have which kernels ... hmm
[12:53] <apw> tgardner, hey ... on this hyper-v thing, do you know its the ata_piix driver which is picking them up or was that just an assumption ?
[12:53] <tgardner> apw, um, I think it was in the email. lemme recheck
[12:54] <apw> tgardner, thanks, i want to do the right one as i can't test myself
[12:55] <tgardner> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917135/comments/3
[12:55] <ubot2> Launchpad bug 917135 in linux "Hyper-V: enable all hv drivers and export them in the initramfs" [Medium,Triaged]
[12:55] <apw> tgardner, thanks, there it is
[13:02]  * apw pops to get a sandwich, i am famished
[13:02] <tgardner> apw, are you using x86_hyper_ms_hyperv.detect(), or is there a better way ?
[13:20]  * tgardner hates hardy openvz
[13:24] <apw> tgardner, there is a standard idiom used in xen where you check x86_hyper == &xxx
[13:25] <smb> xen/hyper/openvz
[13:25] <smb> ?
[13:25] <apw> tgardner, see chinstrap:~apw/P
[13:29] <tgardner> apw, looks about right
[13:30] <apw> tgardner, the naming is a bit ass, but hey.  will put some kernels up for them to test i guess and see what they say
[13:30] <tgardner> apw, do you think its upstreamable ?
[13:31] <apw> well the current situation is that you have to either use blacklisting or link order to determine which gets priority
[13:31] <apw> which to me is utter pants, so unless it has something like xen
[13:31] <apw> where you can backchat to the hypervisor and remove the disks from sata
[13:31] <apw> then i suspect this is the sort of thing one would want
[13:31]  * smb shudders
[13:31] <tgardner> apw, how can you blacklist ata_piix when its built-in ?
[13:31] <apw> so ... they will not like it, but i think its a sensible solution
[13:32] <apw> tgardner, well indeed, you can't so then you have to use link order
[13:32] <apw> and build them both in, and as it is staging you arn't going to do that
[13:32] <apw> but ... even if it was a full driver, that link order or blacklisting is needed
[13:32] <tgardner> nope, doesn't seem sensible to build in a staging driver
[13:32] <apw> that cannot be a good situation
[13:32] <apw> and so i think some way to chose via the command line, with a logical default that works
[13:33] <apw> regardless of order, regardless of which are builtin is needed
[13:33] <apw> and this is that at least
[13:33] <apw> will get them to test it and see
[13:36] <tgardner> apw, so how are you gonna suggest they load their staging drivers in the initrd ? /etc/modules ?
[13:38] <apw> tgardner, i think i saw their modules are discoverable, there is some bus they have id's on
[13:39] <apw> so as long as they are in there they should load
[13:39] <tgardner> apw, hmm, will we need to get them in udebs ?
[13:39] <apw> tgardner, i have that on my list too yes, to put them in the initrd and in di in both cases in the same place as the xen modules
[13:40] <smb> apw, Well, we built those in now, remember? :)
[13:40] <apw> heh yeah, but the configuration is still there in both cases just in case we ever can take them out again
[13:41] <smb> yeah, one never knows
[13:43] <smb> tgardner, Oh btw, about testability of that hardy cve: need to try, but it sounds like it should be possible by trying a mknod
[13:44] <tgardner> smb, the patch seems like the right thing to do. at the very least, I don't think we can make things any worse then a BUG()
[13:45] <smb> tgardner, Yes, but you are right. I'll set up a vm and see if we cann get some more proof as well
[13:45] <smb> And no, BUG seems the worst possible way of a falltrhough
[13:50] <cking> one wonders how such code exists in the first place really
[13:51] <tgardner> cking, it seems like forgotten debug code, or was considered a possibility that could never happen (but just to be safe we'll BUG)
[13:55] <cking> glad automotive firmware isn't like that 
[13:55] <tgardner> cking, or aeronautics software :)
[13:56] <cking> perhaps I'll take a boat next time I travel..
[13:56]  * tgardner works on hardy build breakage
[13:56] <tgardner> cking, just not one of those cruise ships that sail too close to the reef
[13:57] <cking> hrm, maybe telecommuting is the only way forward after all
[14:10] <apw> cking, is rather risk averse today
[14:12] <cking> apw, kids made me that way
[14:16] <apw> heh, you should have been more adverse earlier 
[14:22] <smb> tgardner, Ok, no clue how whether there is a way to exploit or not. I cannot make the stupid thing allow me to do any real mknod on nfs4 and fail that way...
[14:23] <tgardner> smb, were there any instructions on mitre.org about how to exploit it ?
[14:23] <smb> tgardner, hell there is not even a single piece of any info there
[14:24] <tgardner> smb, I'm wondering if this is one of those theoretical exploits. maybe we can just ignore it.
[14:25] <apw> have you tried looking for the lkml thread on the patch that fixed it ?
[14:25] <apw> as if it was theoretical it seems odd that they would bother fixing it
[14:26] <tgardner> apw, I'm wondering if it applies to 2.6.24 at all. the upstream patch is ginormous
[14:29] <smb> Well I am pretty sure there, they just used an opportunity to change that as well
[14:29] <tgardner> BenC, hardy openvz was such a bad idea. how did we ever get roped into that ?
[14:29] <smb> apw, But there is no thread pointed to directly
[14:29] <smb> apw, Just a rh bugzilla and you know how useful those are
[14:30] <BenC> tgardner: we were swooned by a sharp tongue 
[14:30] <BenC> tgardner: does anyone actually use it?
[14:30] <tgardner> no doubt. where are they now? maintenance is a huge pain in the ass
[14:30] <smb> apw, But maybe I misread the description. They talk of mknod() as the C function and ordinary files
[14:30] <smb> apw, So I may need to have something compiled to check
[14:31] <tgardner> BenC, I'm seriously considering discontinuing openvz maintenance.
[14:32] <apw> tgardner, was it ever anything other than a port ? 
[14:32] <tgardner> apw, its always been a community supported flavour, as was xen
[14:33] <smb> There was a community? or just zul ? ;-P
[14:33] <apw> tgardner, so perhaps it is time to ask for a volunteer or lose it
[14:33] <zul> best community ever :)
[14:33] <tgardner> actually, at the time, there was a fairly rabid bunch of openvz dudes
[14:34] <apw> yeah, but is there any chance they are still on .24
[14:35] <tgardner> apw, bjf - I'm gonna float the idea of dropping openvz on ubuntu-devel
[14:36] <apw> it is a vast heap of crap sitting on the top
[14:36] <tgardner> apw, either that, or flatten the development tree like we discussed a few months ago and simply not apply some CVEs. I dunno which is better.
[14:39] <apw> tgardner, i have those patches sitting in my hardy tree.  meant to talk about them at rally and we never got round to it
[14:39]  * apw will dig them out
[14:40] <tgardner> apw, I'm just gonna hit this with a big hammer. I don't care how big the damn repo gets
[14:40] <apw> tgardner, ok
[14:48] <apw> smb, this squid thing, have you used it in the context of a chroot build ?
[14:50] <smb> apw, No in the context of cobbler installs first, and now actually as a current replacement for apt-cacher-ng
[14:50] <apw> but you haven't converted your chroots to use it
[14:50] <smb> (so for all other things) but not yet used it to feed a schroot setup
[14:51] <apw> bah i was hoping to not be first runnign down this road
[14:51] <smb> The problem with the schroots was that the did not work wekk with normal proxy config. I used (maybe only a feature of apt-cacher-ng) the way to have it act as a mirror
[14:54] <BenC> tgardner: wasn't there a company that was supporting it?
[14:55]  * smb wonders whether precise-desktop will become installable before the weekend
[14:55] <tgardner> BenC, too long ago, can't remember
[15:00] <smb> tgardner, apw Ah, it seems I got a reproducer now
[15:02] <apw> smb, sounds good
[15:02] <apw> smb, i think i have found a way to do the configuration in a chroot as well, not using avahi
[15:03] <apw> smb, not sure if i can use it when buildign or not, but maybe able to frig that using 'http_proxy'
[15:04] <smb> apw, MAybe, just remember it was not straight forward using the mirror argument to debootstrap as that wanted a real mirror not a proxy
[15:06] <apw> yeah, i remember using that special form that apt-cacher-ng groked
[15:06] <apw> smb, i suspect that setting http_proxy will do the trick too though
[15:06] <apw> will try it next time
[15:08] <smb> apw, Would be interesting to know
[15:09] <apw> it is an http proxy after all, if you think about it
[15:10] <smb> apw, Sure, I just wonder whether debootstrap honours that variable
[15:10] <smb> at least for the initial setup
[15:10] <apw> i guess we'll find out shortly
[15:10] <apw> it would be stupid if it didn't really
[15:10] <apw> you still have to hand configure it inside of course afterwards
[15:11] <smb> tgardner, If you succeed in un...
[15:11] <smb> err correct hardy repo, let me know
[15:11] <tgardner> smb, yeah, it'll take a bit yet
[15:13] <apw> tgardner, you gonna turn them back into patch stacks sitting on diffent parts of the directories ?
[15:14]  * smb remembers something about unpacked additional subdirs
[15:14] <tgardner> apw, to start with I'm just gonna flatten openvz and implement some checks to make sure patches applied to root sources have also been applied to flattened sources. likely at insertchanges time
[15:15] <apw> tgardner, ok, we'll maybe want a way to not do so
[15:15] <apw> i guess we can put a fake commit down of course
[15:15] <tgardner> apw, right, an exceptions list
[15:15] <tgardner> it might be a bit of a pain in the ass, but certainly less of one then the way we're doing it right now
[15:16] <smb> pop
[15:16] <apw> tgardner, so you gonna like look for patches in pairs, or that each patch if its not in debian, that its got components in 'main' and 'openvz'
[15:17] <tgardner> apw, dunno, haven't gotten that far yet.
[15:18] <apw> tgardner, if we did the latter, then we could do the exceptions by simply editing openvz/exceptions and it would pass
[15:21] <apw> tgardner, would it help if i spin you a 'patch' validate to do that ?
[15:21] <apw> tgardner, i have a framekwork here which does something similar to categorise patches for the reconcile stuff leann uses
[15:22] <tgardner> apw, isn't it beer time for you yet?
[15:22] <apw> tgardner, not for a couple of hours yet
[15:22] <apw> tgardner, i'll put a prototype together, you can make what you will of it
[15:23] <apw> tgardner, where are you putting the non-main flat trees in the main tree as it were
[15:23]  * ogasawara back in 20
[15:24] <tgardner> apw: debian/binary-custom.d/$*/src
[15:52] <apw> tgardner, ok in chinstrap:~apw/validate-patch-range is a perl thingy which will look at a list of commits ... those not marked Ignore: yes and which affect outside debian; it checks that each affects files in each of the places mentioned in '@ports'
[15:53] <apw> tgardner, this fits with the 'one patch for all ports at once' approach
[15:53] <tgardner> apw, does it accept a range of SHA1s ? it shouldn't check anything before Ubuntu-2.6.24-30.98
[15:54] <apw> tgardner, it takes a sha1 pair, and uses them to make foo..bar for checking
[15:54] <apw> tgardner, i envisioned you using it in printchanges ... which has those two at least in precise
[15:55] <tgardner> apw, ok, I'll get it in a couple. I just got the build working.
[15:55] <tgardner> the falttened
[15:55] <tgardner> the flattened build*
[15:55] <apw> tgardner, sounds good
[15:58] <apw> i suspect the following added to 'insertchanges:' will do teh trick
[15:58] <apw>         perl -w -f debian/scripts/misc/validate-patch-range Ubuntu-$(release)-$(prev_revision) $(HEAD)
[15:59] <apw> it should exit appropriatly
[16:04] <tgardner> apw, git://kernel.ubuntu.com/rtg/ubuntu-hardy.git custom-binary
[16:04] <tgardner> bbias, need breakfast
[16:15] <ogasawara> apw, tgardner: I was planning an upload today, but there's a gcc update coming down the pipe.  So I'll probably wait till monday to load since there's nothing critical.  If there is anything you want included, shove it in the tree.
[16:15] <apw> ogasawara, yay ...
[16:16] <tgardner> ogasawara, ack. that'll give us time to finish the azure changes
[16:32] <apw> apw@dm$ fdr insertchanges
[16:32] <apw> 7bce357ca6063903b2061d31a78080575abeb9d6: not ported to openvz
[16:32] <apw> make: *** [insertchanges] Error 1
[16:34] <apw> tgardner, git://kernel.ubuntu.com/apw/ubuntu-hardy.git custom-binary
[16:39] <bjf> brendand: still testing 3.0.0-16.28 ?
[16:41] <brendand> bjf - pretty much done. one problem system
[16:41] <apw> tgardner, that works pretty well
[16:42] <bjf> brendand: ack, thanks
[16:42] <apw> tgardner, though i am going to need more disk space for the working-directory :/
[16:42] <tgardner> apw, a bit more, yes
[16:42] <apw> tgardner, is this going to tripple the size of the sourcepackage ?
[16:43] <apw> tgardner, or do you render it to a patch still for the upload
[16:43] <tgardner> about, but it got pretty ;arge when it was copied to the build dierctory anyways
[16:43] <tgardner> large*
[16:43] <apw> the build is less of a problem than the src package itself as that is 'real'
[16:43] <tgardner> apw, no, I took the simple approach and flattened it. the source package will get much larger.
[16:44] <tgardner> but its all compressed
[16:44] <apw> tgardner, one option would be to exclude the */src directories, and make insertchanges build the diff between the top and the each src and add it as 0000-everything.patch
[16:44] <apw> but i'll let you see how much bigger they get, as you say they are comprssible
[16:45] <tgardner> apw, yeah, developing a patch at package time is a possibility
[16:56] <apw> tgardner, so how big is a src package right now without doing that
[16:56] <apw> tgardner, as the ones in precise are of the order of 90M already anyhow
[16:56] <tgardner> apw, dunno yet
[16:57] <apw> and i think hardy was a lot smaller at base, so we have some space to play with
[16:57] <tgardner> apw, I'll run a quick package phase to see.
[16:59] <tgardner> after first getting the orig tarball
[17:06] <apw> tgardner, i worry that as we have an orig for hardy that what will happen is the diff will become the size of the original tarball as it cannnot share the identicle files
[17:06] <tgardner> apw, I think the diff will be twice the size of the orig
[17:07] <apw> tgardner, we won't be popular :/
[17:07] <tgardner> I'll look at building a patch at package time. I'm still working out build issues.
[17:07] <apw> tgardner, i guess if you do that you don't need to change the build support then, you can just use the existing, making 0000-patch
[17:11] <tgardner> apw, 
[17:11] <tgardner> -rw-rw-r--  1 rtg rtg 4.7M Jan  3 01:06 linux_2.6.24-30.98.diff.gz
[17:11] <tgardner> -rw-rw-r--  1 rtg rtg 2.9K Jan  3 01:06 linux_2.6.24-30.98.dsc
[17:11] <tgardner> -rw-rw-r--  1 rtg rtg 121M Feb 10 10:09 linux_2.6.24-31.99.diff.gz
[17:11] <tgardner> -rw-rw-r--  1 rtg rtg  57M Jan 13  2011 linux_2.6.24.orig.tar.gz
[17:11] <apw> tgardner, ow
[17:11] <tgardner> yeah. I'll finish up the build fixes, then look at packaging
[17:11] <apw> tgardner, well that was my point, if you decide you are making patches
[17:12] <apw> tgardner, then ... you don't need any build changes, just zap the patches we have
[17:12] <apw> tgardner, and place the generated one in the same place
[17:13] <tgardner> apw, how is that any different then what we had before ? you're still working on a patch of a patch. I'd rather generate the final patch at package time.
[17:13] <tgardner> from the flattened sources
[17:20] <brendand> bjf, all ready to go
[17:21] <apw> tgardner, ok so what do you think about adding the hyper-v modules to the virtio-modules udeb
[17:21] <tgardner> apw, that I'm OK with. I just didn't think we should build 'em in
[17:21] <apw> yeah, they are not stable enough to be definatly initialised on everyones machine, yack
[17:22] <tgardner> apw, they are going mainline with 3.3, so maybe we can pull 'em back to 3.2
[17:22] <vanhoof> bjf: ping
[17:22] <vanhoof> bjf: usb 3 device has arrived
[17:22] <vanhoof> bjf: whatever you need done, happy to do
[17:23] <vanhoof> bjf: I am running Oneiric though, but can do a fresh install of Precise if needed
[17:23] <tgardner> vanhoof, you could just install the precise kernel. no need to wreck your user space
[17:23] <bjf> vanhoof, plug it in, don't choose "remove safely", just pull it out
[17:23] <vanhoof> tgardner: complete test machine, so I dont care to reinstall
[17:24] <vanhoof> if you'd like "pristine" testing done :)
[17:24] <bjf> vanhoof: then plug it in and see if the port is "dead"
[17:24] <vanhoof> bjf: also do you have a preference of native uefi or legacy bios mode?
[17:24] <bjf> vanhoof: not that i know of
[17:24] <vanhoof> bjf: ok, let me pxe boot this thing and get precise installed
[17:25] <cking> vanhoof, perhaps UEFI to start with
[17:25] <vanhoof> bjf: any conditions around fs on the device?
[17:25] <bjf> vanhoof: oneiric
[17:25] <vanhoof> vfat/ext3
[17:25] <vanhoof> bjf: oh you want this on oneiric?
[17:25] <bjf> vanhoof: yup
[17:25] <vanhoof> bjf: would you like me to move back to the -15 abi kernel?
[17:25] <vanhoof> currently running this -16 build ogasawara put together for me
[17:25] <vanhoof> for this: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=35970f2894ffe2ecbddfa776995883a96a828fe0
[17:25] <bjf> vanhoof: any oneiric should do
[17:26] <bjf> vanhoof: this is to verify an existing, non-fixed bug does indeed exist
[17:28] <vanhoof> bjf: ok doing so now
[17:28] <vanhoof> one sec
[17:30] <vanhoof> plugged it, it automounted
[17:30] <vanhoof> pulled it out, it dissappered from my screen
[17:30] <vanhoof> plugged it back into the same port, it automounted
[17:30] <bjf> huh
[17:31] <bjf> vanhoof: i'll forward the email to you to make sure you read it the same as I do
[17:32] <vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/
[17:32] <vanhoof> -1 is just when I plugged it in and a few other tidbits, -2 is full dmesg
[17:33] <ogasawara> bjf, vanhoof: I think you had to "eject" or unmount from the command line, then remove the device to trigger it?
[17:40] <bjf> vanhoof: ogasawara is correct
[17:40] <vanhoof> bjf: same manufacturer, but diff device
[17:40] <vanhoof> i bought 
[17:40] <vanhoof> http://www.amazon.com/Patriot-Memory-Direct-Supersonic-PSF16GXPUSB/dp/B005EWB17A/ref=pd_vtp_e_4
[17:41] <vanhoof> since it was a lot cheaper than the one linked in the email
[17:42] <bjf> vanhoof--
[17:42] <vanhoof> ok
[17:42] <vanhoof> so you want me to plug it in
[17:42] <vanhoof> eject /media/foo
[17:42] <vanhoof> then pull it out, pop it back in and see it it works?
[17:43] <vanhoof> is that right?
[17:43] <vanhoof> i just yanked it out w/o ejecting it
[17:48] <vanhoof> bjf: works for me
[17:48] <vanhoof> bjf: plug in (it automounts); eject /media/foo; unplug it; plug it back into the same usb 3 port; it automounts; I can write to it just fine
[17:49] <vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/bjf-3.txt
[17:49] <vanhoof> dmesg from that test
[17:49] <cking> didn't fail after a S3 or was that me making things up?
[17:49] <bjf> vanhoof: thanks, i think that is the right sequence
[17:50]  * vanhoof wonders if bjf is pulling his leg
[17:50] <vanhoof> :)
[17:50] <bjf> vanhoof: would i do that?
[17:50] <vanhoof> bjf: yes :)
[17:52] <vanhoof> ogasawara: let me go back to -15
[17:52] <vanhoof> for fun
[17:52] <vanhoof> brb
[17:54] <bjf> vanhoof: you are using the USB3 port right? and the "bios" has USB3 enabled?
[17:55] <bjf> vanhoof: the dmesg looks like it is
[17:57] <vanhoof> bjf: yes :)
[17:57] <vanhoof> the pretty blue one
[17:57] <vanhoof> and have used the same port each time
[17:58] <cking> smb, http://www.youtube.com/watch?v=K_BX6GB-b00
[17:59] <vanhoof> bjf: this might be interesting
[18:00] <vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/bjf-4.txt
[18:00] <vanhoof> notice when I eject, the error that spits out
[18:00] <vanhoof> but its not listed as mounted anymore, and I pulled it out and plugged it back in and its fine
[18:00] <vanhoof> http://ouwish.com/~vanhoof/pickup/bjf/bjf-5.txt [ full dmesg ]
[18:01] <bjf> vanhoof: thanks for testing, not sure what to say at this point
[18:05] <ogasawara> bjf, vanhoof: I think it was mentioned the bug might only triggered for a specific device or system, so you might not have the right combination
[18:06] <vanhoof> ogasawara: well you know which system I have for sure :)
[18:06] <vanhoof> ogasawara: on the latest bios as well, and the upgrade kit
[18:06] <vanhoof> ogasawara: so maybe this isnt that big of a deal if i cant reproduce with a run of the mill usb 3.0 stick from the same manufactorer
[18:08] <vanhoof> ogasawara: bjf: if they come back w/ anything else lmk
[18:10] <vanhoof> bjf: ogasawara: if either of you want shell access to it I can set that up too
[18:14] <bjf> vanhoof: thanks but that won't be necessary
[18:20] <apw> ogasawara, tgardner, ok i have the fixes for the hyper-v stuff all ready, am wainting on the requstor to test the combination
[18:20] <apw> ogasawara, i will push the d-i bits shortly so that they definatly make the next upload
[18:20] <vanhoof> anyone know of any good benchmarks for usb devices?
[18:20] <vanhoof> i'd like to see exactly what kinda performance increase this thing has to offer
[18:20] <ohsix> dd? :O
[18:20] <vanhoof> (and can you even boot from usb3 yet) ... last I checked you couldnt
[18:20] <ogasawara> apw: ack.  I just pushed one last patch, so you may need to rebase.
[18:21] <vanhoof> ohsix: I thought there was something the Linaro folks had, flash-bench or something like that
[18:21] <vanhoof> i cant recall
[18:21] <ohsix> i just use the benchmark thing in palimpsest
[18:21]  * smb is now know as done-for-the-week
[18:23] <apw> ogasawara, ok pushed that piece, waiting now for confirmation of the other bits
[18:23] <ogasawara> apw: ack
[18:27]  * apw calls it a day ... will be vague at best from here on out
[18:56]  * tgardner -> lunch
[19:15] <hrw> hi people
[19:15] <hrw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/930340 - how can I help to check it?
[19:15] <ubot2> Launchpad bug 930340 in linux "WiFi usage makes kernel panic" [Undecided,New]
[19:19] <vanhoof> ohsix: I have too as well :)
[19:19] <vanhoof> http://people.canonical.com/~vanhoof/random/sdp-ssd-read-perf.png
[19:19]  * vanhoof loves that picture
[19:29] <jsalisbury> hrw, I just posted some comments to bug 930340
[19:29] <ubot2> Launchpad bug 930340 in linux "WiFi usage makes kernel panic" [Undecided,New] https://launchpad.net/bugs/930340
[19:29] <hrw> ok
[19:30] <jsalisbury> hrw, basically a request to test the latest mainline kernel, and to confirm that the latest Oneiric kernel does not have the issue.
[19:30] <hrw> jsalisbury: the problem is that this bug is not reproductible
[19:30] <hrw> I was able to work 6h without oops
[19:30] <jsalisbury> hrw, Hmm, so did it only happen once, or does it happen randomly, but will eventually happen.
[19:30] <hrw> but also I got 3 oopses during 10 minutes
[19:31] <hrw> fetching mainline one anyway
[19:31] <jsalisbury> hrw, great thanks.  It would be good if you could run that kernel for some time and see if the panics still happen.
[19:32] <hrw> sure
[19:32] <jsalisbury> bbiab
[21:31]  * tgardner -> EOD