[02:56] <rpereira>  Hi, I updated my desktop with Feisty RC and I'm getting on booting: "Error 17: Cannot mount selected partition". What can I do?
[02:56] <crimsun> which kernel is this?
[02:56] <rpereira> I updated 2 hours ago.
[02:57] <crimsun> so, -15.27? Can you verify?
[02:57] <rpereira> I know is 2.6.20-15
[02:57] <rpereira> How can I verify if it isn't booting at all?
[02:58] <crimsun> boot from a desktop cd, chroot, dpkg -l linux-image-2.6.20-15-generic
[02:59] <rpereira> OK.
[02:59] <rpereira> I will do it.
[02:59] <rpereira> Which version is working?
[03:00] <crimsun> -15.27 WFM, but I don't have affected hardware
[03:00] <rpereira> OK.
[03:00] <rpereira> I will keep my notebook kernel for security reasons.....
[03:03] <rpereira> I'm burning the CD, so wait some minutes please.
[03:13] <rpereira> crimsum: 2.6.20-15.27
[03:13] <rpereira> crimsun: 2.6.20-15.27
[03:16] <rpereira> crimsun: kernel 2.6.20-15.25 works with this computer.
[03:16] <crimsun> which mass storage controller(s) do you have?
[03:16] <rpereira> If I install on chroot, will I have a problem?
[03:17] <crimsun> at this point, the regression from -15.25 is what's interesting.
[03:18] <rpereira> OK. Mu mass storage controller is: product: 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE
[03:18] <rpereira> Driver:  driver=ata_piix
[03:19] <rpereira> Do you need another info?
[03:20] <crimsun> lspci -vvn
[03:20] <crimsun> should be identical to mine
[03:20] <kylem> dmesg is what we need
[03:23] <rpereira> kylem: how do I get dmesg with the defectuous kernel?
[03:25] <kylem> photograph it or something?
[03:26] <rpereira> But when I use the defectuous kernel, my computer get stucked on grub with message: "Error 17: Cannot mount selected partition"
[03:26] <crimsun> I've resorted to writing dmesg in the past. Not fun, but certainly feasible.
[03:30] <rpereira> I think that I found the error....
[03:31] <rpereira> At least my computer error.
[03:31] <rpereira> When I'm installing a kernel with my CD using chroot and dpkg -i linux-image.... I got the error:
[03:32] <rpereira> findfs: Unable to resolve 'UUID=XXXXXXXXXXX...XXXXXX'
[03:33] <rpereira> Cannot determine root device. Assuming /dev/hda1
[03:33] <rpereira> This error is probably caused by an invalid /etc/fstab
[03:33] <rpereira> That was the error... Sorry for so much pasting...
[03:34] <rpereira> My sda1 is my /home
[03:36] <rpereira> The UUID printed is correct, but my / partition is hda3.
[03:36] <rpereira> So my /etc/fstab is corrected.
[03:40] <rpereira> I just had to manually change the root on "/boot/grub/menu.lst" from (hd0,1) to (hd0,2).... And I don't hava any problems anymore with kernel 2.6.20-15.27.
[03:41] <rpereira> s/hava/have
[03:42] <rpereira> Summarizing: The problem is with the auto generation of grub menu.lst file.
[03:43] <pokoko> rpereira, why use UUID in the first place ?
[03:43] <pokoko> rpereira, just delete the UUID
[03:45] <pokoko> is there donkey kong available for ubuntu. :P
[03:45] <rpereira> I do not use it. Some time on updating Ubuntu change from /dev/sdaX to UUID...
[03:45] <pokoko> ok ok.
[03:45] <pokoko> :)
[03:46] <lamont> so if I have a generic headless P2-233 machine doing server-esque stuff, do I want -server or -generic or -686, I wonder?
[03:46] <rpereira> crimsun: did you got my messages?
[03:47] <crimsun> rpereira: sorry, was away. Yes, I just read scrollback.
[03:47] <crimsun> so the kernel is fine, which is a relief, but the upgrade somehow broke?
[03:47] <rpereira> Yeap.
[03:48] <rpereira> Maybe it is the post-instalation script or grub (if it was upgraded).
[03:49] <rpereira> crimsun: Please report this to kernel team (if you're not part of kernel team), my battery is dying.... :-) Thanks for your help.
[03:51] <kylem> lamont, a p2? -generic
[03:53] <lamont> kylem: yeah - iz glorified printer server
[03:53] <lamont> state of the art about the time you were born... :-)
[03:53] <lamont> oops.  ECHAN
[06:33] <rajlinux> Hi, I am searching for any article describing the serial driver layer changes from Linux kernel 2.4 to 2.5..can anybody help me?
[06:35] <crimsun> please see LWN.net archives.
[06:39] <rajlinux> I cant find there
[06:39] <rajlinux> is there any other place to search?
[06:40] <rajlinux> there was one serial.c file in 2.4 and now there is one drivers/serial directory with more than 10 files.. I want to how it was divided..
[08:35] <drago> Hi, does anyone working on bug abt /proc/kcore ?
[08:39] <cjwatson> Nafallo: being unable to sync with Debian is unfortunate, but not a totally overriding concern
[08:39] <cjwatson> and if we ask nicely it's possible that Debian might add the epoch too
[08:42] <Mithrandir> morning, Colin
[11:07] <heno> Any views on bug 106864? It was reported during testing of 20070415, the latest images. It's different from the sata_nv problems that were fixed, but still looks like a regression.
[11:08] <heno> bug 106864
[11:10] <Mithrandir> ubotu isn't in here
[11:26] <cjwatson> heno: too little information to be able to diagnose; I've posted a message requesting more information
[11:27] <heno> cjwatson: ok, thanks. almost seems like a bad disk, but ideally the kernel should cope, no?
[11:27] <cjwatson> I see no reason to infer a bad disk from that
[02:30] <zul> g'day
[02:34] <gortiz> hi zul
[02:46] <mdz> kylem: this VMWare performance issue has now been confirmed by Keybuk
[02:46] <mdz> kylem: I'm guessing it's something to do with the PIIX driver changes
[02:46] <kylem> hmm, bug #?
[02:47] <kylem> i'll take a look
[02:49] <mdz> kylem: hadn't reported it yet since I thought it was a problem with this PC
[02:49] <mdz> kylem: installing current dailies in vmware with ubiquity takes much, much longer than it did before
[02:49] <kylem> any idea which day it changed? :\
[02:49] <kylem> (approximately)
[02:50] <mdz> kylem: yes, I mentioned it in this  channel
[02:50] <mdz> let me find the log
[02:51] <mdz> kylem: first noticed 12 April ~16:56 BST
[02:51] <kylem> ok, thanks.
[02:52] <kylem> could i get a dmesg from one of the booted vmware instances?
[02:52] <mdz> kylem: yep
[02:53] <kylem> awesome.
[02:57] <mdz> kylem: http://people.ubuntu.com/~mdz/temp/dmesg
[02:57] <kylem> thanks.
[02:58] <mdz> default vmware config for Ubuntu (SCSI disk, ATAPI CD-ROM)
[02:59] <Keybuk> mdz: http://people.ubuntu.com/~scott/dmesg.vmware-live
[02:59] <Keybuk> (booting the Live CD)
[02:59] <mdz> Keybuk: 403
[03:00] <Keybuk> fixed
[03:01] <mdz> Keybuk: is not
[03:01] <Keybuk> err
[03:02] <Keybuk> fixed harder
[03:03] <cjwatson> pkl_: can you help kyle with this? kyle has been doing pretty long hours lately. :)
[03:04] <pkl_> Ok
[03:04] <pkl_> Keybuk: fixed for me (403 err)
[03:05] <kylem> hm, do you recall offhand if prior to the slow down it was using libata for the cdrom (so it would have been scd0?)
[03:05] <cjwatson> pretty sure vmware was using ata_piix before
[03:05] <mdz> kylem: no, I don't
[03:06] <Keybuk> let me grab a beta CD and compare
[03:06] <kylem> Keybuk, thanks.
[03:07] <Keybuk> downloading...
[03:07] <kylem> i don't see how this could drop the performance though, this driver is what would have been using for years pevious
[03:07] <mdz> I have a beta install in vmware already
[03:07] <mdz> kylem: maybe the new driver made things much faster?
[03:08] <kylem> hrm.
[03:08] <mdz> I can see the difference just booting the live CD
[03:08] <mdz> comes up much quicker
[03:08] <mdz> kylem: do you not have vmware locally?
[03:09] <mdz> kylem: yes, beta used scd0 and ata_piix
[03:10] <mdz> kylem: is it possible to force ata_piix in current feisty to test?
[03:10] <Keybuk> how come we reverted from libata to ide for that driver?
[03:10] <mdz> Keybuk: because the new one was fucked
[03:11] <kylem> no, we reverted for pata_amd...
[03:11] <mdz> keybuk: bug 96857
[03:11] <pkl_> Pre-moving over to libata (-12 kernel), the cdrom driver would resumably have been this driver?
[03:11] <pkl_> s/resumably/presumably/
[03:12] <kylem> mdz, oh.
[03:12] <Keybuk> so we broke vmware to fix qemu?
[03:13] <cjwatson> as kyle says, vmware probably used to use piix
[03:13] <cjwatson> can somebody boot dapper and/or edgy to test? my vmware box is doing other things at the moment
[03:14] <cjwatson> Keybuk: weren't you seeing ATA errors in vmware too?
[03:14] <cjwatson> that was one of the rationales for reverting IIRC
[03:15] <Keybuk> cjwatson: I was seeing lots of messages, yeah -- but it did at least work
[03:15] <cjwatson> if it worked, why was it being brought up as an issue near release time?
[03:15] <pkl_> keybuk: it works now, but slowly?
[03:16] <Keybuk> I brought it up quite a long time before release time :)
[03:17] <pkl_> before libata, the piix driver would have been used for both CDROM and hard-disks?  Now libata is being used for hard-disks, and piix for CDROM.  If I understand correctly?
[03:18] <kylem> in the case of vmware, we're using a virtual scsi disk for hard disk
[03:18] <kylem> argh, Stanislaw and Dmitry hijacked that bug with an unrelated issue.
[03:19] <mdz> pkl_: we're using SCSI hard disks, which is the default
[03:19] <cjwatson> pkl_: vmware gives you the option of selecting SCSI (BusLogic or LSILogic) or IDE
[03:20] <Keybuk> http://people.ubuntu.com/~scott/dmesg.vmware-beta
[03:20] <mdz> cjwatson: the error messages were sufficiently scary that it didn't seem wise to ignore, even if it appeared to work
[03:21] <mdz> I don't see the errors with beta, and performance is good there
[03:21] <pkl_> OK.  I've never used vmware :)  So the virtual scsi disk isn't handled by libata anyway?  Just the CDROM that was handled by piix, then libata, and now piix again?
[03:21] <mdz> pkl_: that's my assumption, yes
[03:22] <cjwatson>     - 96857: Broken PIIX support, mostly showed under emulation. This
[03:22] <cjwatson>       affected qemu, kvm and vmware. All of which have an emulated PIIX
[03:22] <cjwatson>       IDE chipset. The disk would work fine, but CDROM support would
[03:22] <cjwatson>       not. Resolved by reverting back to piix.ko (IDE) for Intel PIIX
[03:22] <cjwatson>       pata chipsets. Piix.ko is much more tested and stable.
[03:22] <mdz> if all we did was switch to the same driver we were using before, I have no explanation for the performance regression
[03:22] <cjwatson> as a reminder, that was Ben's rationale
[03:22] <mdz> cjwatson: yes, Ben said he had reports of it actually not working
[03:22] <pkl_> Could the slow down be completely unrelated?
[03:22] <mdz> though we weren't able to reproduce them in our setups
[03:22] <cjwatson> he also explained by phone that it affected some older hardware
[03:22] <mdz> pkl_: there is always that possibility, yes
[03:22] <Keybuk> pkl_: SCSI doesn't need to go through libata ;)
[03:22] <mdz> pkl_: do you know of any other changes which may have caused it?
[03:23] <Keybuk> beta was using ata_piix, today is using piix
[03:23] <mdz> pkl_: did we pull a libata update post-beta?
[03:24] <mdz> Keybuk: yeah, just pondering that
[03:24] <mdz> so beta had neither performance problems nor errors with ata_piix
[03:24] <cjwatson> this suggests that piix has regressed seriously since dapper/edgy/whatever, and that we just haven't noticed it since not enough people are using piix any more
[03:24] <mdz> yet we reverted to piix to fix the errors?
[03:24] <Keybuk> mdz: confirmed
[03:24] <Keybuk> cjwatson: regressed since *beta*, not edgy or dapper!
[03:24] <mdz> Keybuk: beta used ata_piix, it may have had this piix problem
[03:24] <cjwatson> beta was using ata_piix so the piix module's behaviour is not known
[03:24] <pkl_> mdz:  I don't know of any changes.  I'll check when the Squashfs update went in, though that shouldn't be causing any issues.
[03:24] <cjwatson> libata update went in post-beta
[03:24] <Keybuk> ah, good point
[03:24] <Keybuk> sorry
[03:25] <mdz> pkl_: this problem began around 12 april
[03:25] <cjwatson> pkl_: squashfs update didn't make final
[03:25] <Keybuk> brain was unsuccessfully on two tracks there
[03:25] <cjwatson> it's in git head but not in the branch that actually landed for release
[03:25] <Keybuk> errors in ata_piix was regression between feisty beta and today
[03:25] <pkl_> cjatson: there was an update from Squashfs 3.1 to 3.2-r2 that did go in...
[03:25] <Keybuk> speed of piix is regression between dapper/edgy and unknown before today
[03:25] <pkl_> this keyboard is playing up... missing characters.
[03:25] <cjwatson> oh, right, I thought you meant squashfs setpageerror
[03:26] <cjwatson> fair point, that could be implicated
[03:28] <cjwatson> can we get lspci -vvnn from vmware, qemu, kvm, parallels?
[03:28] <cjwatson> it would be useful to know if vmware has different pci ids from the others, in which case the adjustment will be obvious
[03:31] <mdz> http://people.ubuntu.com/~mdz/temp/lspci-vmware
[03:31] <mdz> cjwatson: ^^
[03:31] <mdz> 00:07.1 IDE interface [0101] : Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111]  (rev 01) (prog-if 8a [Master SecP PriP] )
[03:34] <cjwatson> ok, that's PCI_DEVICE_ID_INTEL_82371AB
[03:35] <Keybuk> when did the reversion happen, btw?
[03:35] <cjwatson> -15.23
[03:36] <Keybuk> my laptop is running 15.27 and has ata_piix loaded, not piix
[03:36] <mdz> BenC: good morning
[03:36] <BenC> mdz: hey
[03:37] <BenC> rough weather here last night...power went out like 6 times
[03:37] <cjwatson> Keybuk: yes it's only for a few pci ids
[03:37] <kylem> mdz, can you past the next line? (the subvendor line)
[03:37] <cjwatson> five, I think
[03:37] <mdz> kylem: URL above
[03:37] <pkl_> parallels (MBP) 00:1f.1 IDE interface [0101]  Intel Corporation 82801BA IDE U100 [8086:244b]
[03:37] <kylem> sorry, missed that, thanks mdz
[03:38] <BenC> did I wake up in the middle of a kernel crisis?
[03:38] <kylem> ok, we want to match on subvendor/subdevice if this is something we want to fix.
[03:38] <cjwatson> qemu is 8086 7010 I think
[03:38] <cjwatson> which is PCI_DEVICE_ID_INTEL_82371SB_1
[03:39] <pkl_> subsystem: Intel corporation unknown device [8086:4541]
[03:39] <cjwatson> so qemu and vmware at least are using different piix drivers, which offers an obvious possibility
[03:39] <mdz> BenC: at least a potential crisis
[03:39] <cjwatson> BenC: serious cdrom performance regression in vmware apparently since the ata_piix to piix reversion
[03:39] <mdz> BenC: do you remember when I mentioned I had slowdown problems in vmware, and was trying to blame it on the host machine or vmware itself?
[03:39] <cjwatson> I'm wondering if we blatted back more than we needed to
[03:39] <mdz> BenC: Keybuk reproduced it in his vmware as well
[03:40] <Mithrandir> how about we just roll a test image with that single re-re-re-reverted?
[03:40] <cjwatson> I don't like just reverting this because it fixed several potential problems
[03:40] <BenC> the bad thing about ata_piix was the exceptions on the cdrom
[03:40] <cjwatson> has anyone checked qemu lately?
[03:41] <cjwatson> or kvm, with current images?
[03:41] <BenC> cjwatson: I had several people confirm qemu working
[03:41] <BenC> I can test kvm real quick
[03:41] <mdz> BenC: we discovered that those appeared sometime after beta
[03:41] <mdz> BenC: beta works with ata_piix just fine without errors and with good performance
[03:41] <BenC> mdz: right, they happened after the drivers/ata/ sync with libata-dev stable
[03:41] <cjwatson> the libata updates weren't done for fun though - they fixed other problems, right?
[03:41] <BenC> right
[03:42] <BenC> mainly they enabled DMA for pata
[03:42] <BenC> which I believe is the source of the exceptions on ata_piix for ATAPI devices
[03:43] <Mithrandir> mdz: check if dma is enabled on your emulated cd drive?
[03:43] <BenC> but disabling DMA for ATAPI in ata_piix would probably get us the same problem that you are experiencing now
[03:43] <mdz> Mithrandir: it is, in both cases
[03:43] <mdz> checked that
[03:43] <BenC> note, we've got near zero changes to drivers/ide/ compared to stock 2.6.20
[03:43] <BenC> only thing of note is ide-acpi
[03:44] <cjwatson> BenC: it's sounding like piix performance has regressed compared to 2.6.17 or so, whenever we were last using piix for vmware systems
[03:44] <BenC> you can disable that with a module param, I can find it if you want to test it
[03:44] <mdz> BenC: when did we switch from piix to ata_piix?
[03:44] <BenC> mdz: for some PCI id's we've been using it since dapper, I believe
[03:45] <BenC> edgy a few more were moved, and for feisty we ended up switching all of them, all based on what upstream was doing
[03:45] <cjwatson> BenC: 8086:7111 is the ID in question
[03:45] <BenC> so it's been a gradual change
[03:45] <BenC> that one would be one of the last to change
[03:46] <BenC> that's why it was part of the 5 moved back to piix during our Great Kernel Fixing Extravaganza
[03:47] <BenC> let me copy a feisty image over and test kvm real quick
[03:48] <BenC> also need to disconnect my generator so I can switch power back to the barn for possible builds
[03:49] <poningru> quick question
[03:49] <poningru> why does the kernel get symlinked to /?
[03:49] <poningru> and the init image as well
[03:49] <cjwatson> historical
[03:50] <poningru> any particular historical reason?
[03:50] <poningru> like sysv spec or something?
[03:50] <cjwatson> it's been like that forever on certain architectures (NOTE not all) and we've never got round to the faff of moving it
[03:50] <poningru> ah hmm
[03:50] <poningru> does deb also follow this?
[03:50] <cjwatson> yes, we inherited it from Debian
[03:50] <poningru> cool thanks mate :)
[03:51] <cjwatson> specifically arm, hppa, powerpc, s390, and sparc put it in /boot instead
[03:52] <cjwatson> it also depends somewhat on the boot loader
[03:52] <poningru> hmm I know grub can load from any place
[03:52] <poningru> oh right ppc have their own dont they
[03:52] <poningru> ok I see what you are saying
[03:53] <cjwatson> there are lots and lots of complications particularly when a separate /boot is involved
[03:53] <cjwatson> so moving the symlink must be done carefully
[03:53] <BenC> poningru: also /etc/kernel-img.conf is what tells it to do so
[03:53] <cjwatson> right, set up by base-installer (d-i) or the live filesystem build script (ubiquity)
[03:54] <poningru> hmm ic
[03:54] <poningru> assuming kpkg will do this for you automagically?
[03:54] <Keybuk> herd-1 took 1:32.6
[03:55] <mdz> BenC: you have a local vmware, right?
[03:57] <BenC> ws6
[03:57] <BenC> I'll try it and kvm
[03:58] <Keybuk> herd-2 took 1:59.3
[04:00] <Keybuk> herd-3 took 1:22.1
[04:03] <Keybuk> herd-4 took 1:29.2
[04:05] <BenC> cool, I have -15.27 images rsync'd already
[04:05] <mdz> BenC: do you see the same problem with ws6, or no?
[04:05] <BenC> getting ready to test
[04:05] <BenC> had to copy it to the laptop
[04:05] <Keybuk> herd-5 took 1:28.7
[04:07] <Keybuk> (all of those were using piix)
[04:08] <Mithrandir> and current is ?
[04:08] <mdz> hmm, so it switched between herd-5 and beta
[04:08] <Keybuk> Mithrandir: current is booting ;)
[04:08] <Mithrandir> ok
[04:09] <Keybuk> mdz: we switched to ata_piix between herd-5 and beta, afaict
[04:09] <Keybuk> and switched back between beta and today
[04:09] <mdz> Keybuk: that's what I just said
[04:09] <mdz> BenC: so what changed in piix since beta, if anything?
[04:09] <BenC> mdz: nothing
[04:10] <mdz> weird
[04:10] <pkl_> what kernel rev did Herd5 use?
[04:11] <BenC> 2.6.20 stable, from what I remember
[04:12] <BenC> wait, I might be wrong about piix changes from upstream...
[04:12] <Keybuk> current is 3:02.7
[04:12] <Keybuk> piix clearly changed between herd-5 and current
[04:13] <mdz> something affecting it did, at least
[04:13] <BenC> nope, there isn't
[04:13] <BenC> piix is exactly the same as 2.6.20 except out PCI id allocation
[04:14] <BenC> s/out/our
[04:16] <Keybuk> beta (with ata_piix) booted in 1:59.5
[04:17] <mdz> interesting, so still slower
[04:17] <mdz> ata_piix was slower than the old piix, and new piix is slower than that
[04:18] <BenC_> that was ugly
[04:18] <BenC_> ws6 locked me up solid
[04:18] <cjwatson> me> the host?
[04:18] <BenC> yeah
[04:18] <BenC> no caps lock, no ping, nothing
[04:19] <BenC> let's give qemu a try
[04:19] <Keybuk> beta booting with piix
[04:19] <mdz> BenC: what about ide-cd? anything different there?
[04:20] <BenC> -#define VERBOSE_IDE_CD_ERRORS 1
[04:20] <BenC> +#define VERBOSE_IDE_CD_ERRORS 0
[04:20] <BenC> that's our only diff between upstream
[04:21] <BenC> and that patch has been in since dapper
[04:21] <BenC> or even breezy
[04:21] <Keybuk> beta (with piix) booted in 1:57.1
[04:21] <BenC> Keybuk: what kernel is in herd 5 and beta?
[04:22] <Keybuk> beta with piix is notably quite perky
[04:22] <BenC> ah, so piix isn't broken in beta?
[04:22] <Keybuk> icons appearing instantly
[04:22] <Keybuk> etc.
[04:22] <BenC> what kernel is in beta?
[04:22] <BenC> cat /proc/version_signature
[04:22] <Keybuk> (I'd put down the slightly slower boot to lack of readahead update before it, since hal/gdm were reordered)
[04:22] <Keybuk> 1.5x isn't "bad" ... 3m is bad
[04:22] <Keybuk> 2.6.20-12-generid
[04:23] <Keybuk> BenC: Ubuntu 2.6.20-12.20-generic
[04:23] <mdz> Keybuk: did you try current with ata_piix?
[04:23] <BenC> ok, thanks
[04:23] <Keybuk> BenC: would a new_id force current with ata_piix ok?
[04:23] <BenC> Keybuk: yes
[04:24] <Keybuk> it should just modprobe though, right?
[04:24] <mdz> BenC: how can I generate a diff from 2.6.20-14.22 to current using git?
[04:24] <Keybuk> (ie. claim if I just load the driver, without needing to force)
[04:24] <BenC> The ONLY changes from 2.6.20-12.20 and our current code in ALL of drivers/ide/ is the piix PCI id moving we've done
[04:24] <BenC> mdz: git-diff-tree -p Ubuntu-2.6.20-14.22..HEAD [paths]  > foo.diff
[04:25] <BenC> if you exclude a path, you'll get everything
[04:25] <BenC> mdz: drivers/ide has changed since before beta
[04:25] <BenC> except for the PCI id's
[04:25] <cjwatson> has changed => has not changed?
[04:25] <BenC> has not
[04:25] <BenC> correct
[04:26] <Keybuk> BenC: err, doesn't seem to be forcing it
[04:26] <BenC> Keybuk: did piix load already?
[04:26] <BenC>  generic.c |    5 -----
[04:26] <BenC>  piix.c    |   19 ++++++++++++-------
[04:26] <BenC> that's the diffstat for beta to now in drivers/ide
[04:26] <Keybuk> no
[04:26] <BenC> the generic.c change  was actually to revert it back to stock (jmicron bug that delayed beta)
[04:27] <BenC> err, that should have delayed beta :)
[04:27] <BenC> we missed it for that milestone
[04:27] <BenC> Keybuk: I can't see how it wouldn't
[04:27] <pkl_> does anyone want me to test parallels for the slowdown?
[04:27] <pkl_> I don't think parallels got the piix reversion? BenC?
[04:28] <BenC> pkl_: it should have
[04:28] <Keybuk> I tried echo -n 0000:00:07.0 > bind as well, that didn't go either
[04:29] <BenC> shouldn't it be "ven dev", not ven:dev?
[04:29] <Keybuk> that's bind
[04:29] <Keybuk> I did echo 8086 7111 > new_id
[04:29] <BenC> oh, right, I get those mixed up
[04:30] <Keybuk> it don't like binding :)
[04:30] <Keybuk> maybe I need to force libata instead?
[04:30] <BenC> ata_piix is the one that has the PCI probe callbacks and device table
[04:31] <Keybuk> ah right
[04:31] <Keybuk> isn't playing anyway
[04:33] <Keybuk> mdz: NOT A CRISIS: http://lwn.net/Articles/229690/
[04:33] <mdz> Keybuk: thanks
[04:44] <BenC> I'm going to give ws6 a try again...wish me luck
[04:44] <Nafallo> BenC: gl
[04:44] <Nafallo> :-)
[04:47] <BenC_> wont be trying this again
[04:47] <BenC_> maybe my 64-bit vmware doesn't like 32-bit CD's
[04:48] <pkl_> BenC: with the latest kernel (built Sun Apr 15), parallels is still using libata for hard disk.  CDROM gets exception Emask blah blah
[04:48] <BenC_> maybe I should disable it from using vmx too
[04:48] <BenC_> pkl_: ven/dev for your chip?
[04:49] <pkl_> BenC: how do I get the exact kernel version (rather than the Uname 2.6.20-15-generic).  Is there a Debian package query?
[04:49] <kylem> pkl_, /proc/version_signature
[04:49] <BenC_> pkl_: cat /proc/version_signature
[04:50] <pkl_> Thanks, -15.27.  I put the ven/dev earlier, but I'll paste it again
[04:51] <pkl_> parallels (MBP) 00:1f.1 IDE interface [0101]  Intel Corporation 82801BA IDE U100 [8086:244b]
[04:51] <pkl_>  subsystem: Intel corporation unknown device [8086:4541]
[04:53] <BenC> pkl_: Boot with break=top, at the prompt, modprobe piix
[04:53] <BenC> exit, and see if things continue along happily
[04:53] <pkl_> OK
[04:53] <mdz> cjwatson: do we have any dailies from before 20070412?
[04:53] <mdz> any isos at all?
[04:54] <Keybuk> (you'll get some dmesg after the modprobe if it worked)
[04:56] <mdz> BenC: if this isn't a piix regression, do you have any theories?
[04:56] <BenC> mdz: let me check drivers/block/
[04:57] <BenC> nope, nothing there either
[04:57] <kylem> BenC, check block/ too
[04:57] <BenC> ah, right
[04:57] <BenC>  0 files changed
[04:57] <pkl_> BenC: yeah, that worked fine.  Cdrom recognised okay (obviously).
[04:57] <mdz> drivers/block has only ps3_storage.c changed
[04:58] <BenC> pkl_: can you check the apparent performance?
[04:58] <cjwatson> mdz: not unless they got released
[04:59] <cjwatson> we simply don't have disk space to keep them - in fact I've been pondering keeping them for one fewer day for a while
[05:00] <mdz> cjwatson: are you aware of any other changes which could have affected this?  toolchain?  livefs build process?  buildd machines?
[05:00] <BenC> http://people.ubuntu.com/~bcollins/since-beta.diff
[05:00] <BenC> that's the diff of the entire tree since beta
[05:00] <mdz> I've looked over that
[05:00] <pkl_> OK
[05:00] <mdz> as has Keybuk
[05:00] <mdz> we didn't spot anything out of sorts
[05:00] <mdz> except that it's enormous, of course
[05:02] <cjwatson> the only close-to-relevant CD build change I know of is that I dropped the hw-detect/start_pcmcia=false workaround
[05:02] <cjwatson> doesn't affect the live CD at all though
[05:04] <BenC> Keybuk, mdz: either of you tried vmware under windows host, to make sure the slow down isn't host side?
[05:04] <Keybuk> the host didn't change between the tests though?
[05:04] <Keybuk> and I've seen this on widely different hosts
[05:05] <BenC> ok, I'm going to have to go on the assumption that this isn't IDE/libata/DMA/piix/ata_piix related
[05:05] <BenC> so that leaves general performance problems
[05:06] <mdz> BenC: my host has been running dapper
[05:06] <BenC> the only way to prove otherwise is to bisect the kernel, always using piix driver, and see if that makes any difference
[05:06] <mdz> any other theories? anyone?
[05:06] <BenC> my vmware seems busted at the moment, but I guess I could get a ws5 image/lic real quick and start testing
[05:06] <mdz> anything goes at this point
[05:06] <Mithrandir> BenC: or run an old kernel in a new image.
[05:06] <mdz> BenC: that would be a good idea
[05:07] <Keybuk> what's this "ACPI Drive" stuff?
[05:07] <Keybuk> oh, it's in ata/
[05:07] <BenC> anyone tried disabling ide acpi yet?
[05:07] <BenC> hold a sec...
[05:08] <Keybuk> is i810 relevant?
[05:09] <BenC> hmm...what video is it using?
[05:09] <BenC> have all these tests been done with livecd, or any alternate testing?
[05:09] <Keybuk> just livecd
[05:10] <BenC> well, any video it's using most likely isn't using agp/drm, so there's no changes that should affect it
[05:10] <Keybuk> I'm installing a beta image, to test pure CD IO performance
[05:10] <Keybuk> was wondering whether the video dma changes could've mucked up IO dma
[05:10] <BenC> ide=noacpi is something else to try
[05:13] <BenC> break=top, modprobe ide-core ide=noacpi
[05:13] <mdz> +Starting balanced_irq
[05:13] <Keybuk> BenC: no particular acpi changes
[05:13] <mdz> BenC: what's that?
[05:13] <BenC> probably has to be done that way
[05:13] <BenC> mdz: acpi is the only notable things in our drivers/ide/ that is not in upstream
[05:13] <mdz> BenC: what's balanced_irq?
[05:14] <BenC> mdz: it balances irq's on SMP systems
[05:14] <BenC> so other than just the first CPU can handle IRQ's
[05:14] <BenC> there was some updates to it to handle multi-core/shared cache a lot better
[05:15] <BenC> but I thought it was in universe
[05:15] <kylem> it is
[05:15] <kylem> i never put it in a MIR for it.
[05:16] <kylem> (since it was post-beta)
[05:16] <mdz> so it does nothing without the userspace bits installed?
[05:16] <BenC> anyone have a quick download for ws5 so I don't have to do this email song and dance?
[05:16] <mdz> (apart from mentioning itself in dmesg)
[05:17] <mdz> BenC: I have a copy here
[05:17] <mdz> can upload it to the DC quick
[05:17] <BenC> mdz: ah, balanced IRQ in kernel, it does some trivial balancing, but nothing major
[05:18] <mdz> BenC: ~mdz on chinstrap
[05:18] <mdz> ETA 5 seconds
[05:18] <BenC> mdz: thanks
[05:20] <BenC> need coffee and a smoke, and few minutes to ponder things at this point
[05:20] <BenC> afk for about 10
[05:29] <Keybuk> hmm, beta is STILL installing!
[05:31] <BenC> one thing I didn't check is changes in pci quirks that might affect piix
[05:32] <mdz> I can't get anything approaching reproducible numbers by timing raw /dev/hdc or /dev/scd0 reads in vmware
[05:32] <mdz> so far our only test cases are booting the live CD and installing in ubiquity
[05:32] <BenC> hmm, changes in combined mode
[05:33] <BenC> but that affects only Intel SATA I think
[05:33] <BenC> splits the pata drive off the combined sata/pata chipset into a separate func
[05:34] <BenC> then  there's MSI, and toshiba/sis quirks
[05:35] <BenC> let me do this ws5 install and try to reproduce so I'm at least working with you guys
[05:37] <BenC> mdz: do you have fixed tarballs for the module source for vmware?
[05:38] <BenC> or do these build ok?
[05:38] <mdz> BenC: not on me
[05:38] <mdz> they wo'nt build, the fix is all over google though
[05:39] <BenC> I forget the name of the update file, do you remember it?
[05:40] <BenC> got it
[05:45] <Keybuk> whatever the line that fails, comment it out
[05:45] <BenC> I can't get the key I pulled from wiki to work
[05:46] <Keybuk> did you pull it from the new page, instead of the old?
[05:46] <Keybuk> it was under Montreal/VMware or something
[05:46] <BenC> yes, the ones marked March 2007 + 180
[05:46] <BenC> one of the keys didn't work, another one did
[05:46] <BenC> I'll not it on the wiki
[05:48] <BenC> ffs, the any-any gave me bad modules versions
[05:55] <mdz> BenC: is this the same machinew here you have ws6 installed? maybe they can't coexist peacefully
[05:55] <BenC> I uninstalled ws6 first
[05:55] <BenC> any-any was too old for this ws5
[05:55] <BenC> so fixing the module source manually
[05:56] <Keybuk> ok, beta is STILL copying off the damned CD
[05:58] <Keybuk> (that's with ata_piix ...)
[06:00] <kylem> Keybuk, can you disconnect a fucked cdrom by booting the installed image in vmware and trying to do heavy i/o off another cd?
[06:01] <kylem> er, discount, not disconnect
[06:01] <Keybuk> how do you mean?
[06:01] <Keybuk> we can't get useful timings from the real cd
[06:01] <BenC_> dear vmware, please stop crashing my system
[06:01] <Keybuk> since vmware's clock invents numbers
[06:01] <Keybuk> and a stopwatch gives different answers too
[06:07] <BenC> anyone tried switching the cd to SCSI instead of IDE to see if that makes a difference?
[06:07] <Keybuk> not yet, am still waiting for this one to install
[06:07] <Keybuk> at which point I can have the VM back for a bit <g>
[06:08] <BenC> I'm going to install vmware on this other machine to see if I can get it to work
[06:15] <cjwatson> has bug 106864 come up on this channel already?
[06:15] <cjwatson> it's unfortunately not too clear what's going on, only fragments of error messages
[06:16] <cjwatson> the comments from Arjan Kon are probably a different bug, but have more detailed results
[06:16] <kylem> looks like he fell to initramfs.
[06:17] <BenC> looks like the exceptions are ata_piix related
[06:17] <Keybuk> "oops, I tripped, and fell, and landed initramfs"
[06:17] <BenC> same as we saw in vmware
[06:17] <Keybuk> yeah they are the same
[06:17] <cjwatson> exceptions> Arjan's, right?
[06:21] <Keybuk> so, err
[06:21] <BenC> cjwatson: yeah
[06:21] <Keybuk> how do you get vmware to boot off an emulated scsi cd-rom?
[06:21] <BenC> Keybuk: the CDROM pref page for the VM should let you select IDE or SCSI
[06:21] <BenC> it did for me at least
[06:21] <Keybuk> yes
[06:21] <Keybuk> but how do you boot off it?
[06:22] <Keybuk> the bios doesn't seem to support that
[06:22] <BenC> uh, it should I guess
[06:23] <Keybuk> why?
[06:23] <Keybuk> you normally can't boot off scsi cdroms
[06:23] <Keybuk> not if there's a boot image on a scsi drive with a lower id
[06:28] <BenC> Keybuk: doesn't vmware have a Boot menu in bios?
[06:29] <Keybuk> yes
[06:29] <Keybuk> PC BIOS can only boot off things like IDE, remember
[06:30] <Keybuk> so "SCSI" tends to be a boot option :p
[06:30] <Keybuk> (booting current with piix and ide=noacpi didn't help)
[06:32] <BenC> if the SCSI controller does the right BIOS setup, then the BIOS shouldn't care that it's a SCSI drive
[06:33] <BenC> s/drive/cdrom/
[06:44] <pkl_> BenC: I got the requested performance figures for LiveCD booting for a number of daily build vintages.  No apparent slowdown in performance in Parallels from 20070301 builds to latest 20070415 build off hard-disk and real CD.
[06:45] <pkl_> tested 20070301, 20070313, 20070411 and 20070415 :)
[06:45] <mvo> could some please check https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/103050 ? if its valid, it looks rather serious
[06:46] <BenC> mvo: what is module wfb?
[06:47] <mvo> BenC: I have no idea, but it seems that the report claims that "nvidia-glx-config enable" adds it and its part of the nvidia binary package
[06:47] <mjg59> It's an X module, not a kernel one
[06:48] <mjg59> Is it in the package? If not, is it in the source package?
[06:48] <BenC> looks legit, so we may need to add it as part of the nvidia-glx-new package
[06:49] <BenC> mvo: I've taken it on
[06:49] <mvo> BenC: thats great, thanks a lot!
[06:59] <BenC> Keybuk: weird that they let you make it a SCSI device and don't let you boot from it
[07:00] <BenC> so what's our guage for this bug?
[07:00] <BenC> I just got to desktop after power on in less than 2 minutes with current livecd
[07:02] <pkl_> Parallels takes 1:01 (iso on hard disk), no performance problems.
[07:03] <pkl_> with latest livecd
[07:04] <Keybuk> BenC: try and install
[07:04] <BenC> starting an install for a more thorough test
[07:05] <BenC> system is using piix right now
[07:05] <BenC> note I'm on a 64-bit intel core2duo install, 32-bit vmware ws5
[07:05] <BenC> oh wait, no, it's a 64-bit Turion x2
[07:07] <Keybuk> I've seen the same on a dual 64-bit athlon x2, sata_nv etc.
[07:10] <Keybuk> BenC: what can we do to help you debug this
[07:10] <Keybuk> since performance in vmware is our prime feature for Ubuntu Server 7.04, this is of showstopper grade
[07:11] <BenC> ahci on the host
[07:11] <Keybuk> ?
[07:11] <BenC> my host for vmware is using achi, was just checking that
[07:11] <BenC> guest is using piix
[07:12] <pkl_> BenC: vmware running on what?
[07:12] <BenC> Keybuk: At the moment, I'm unable to reproduce any real performance issue
[07:12] <Keybuk> both mdz and I are
[07:12] <BenC> Turion x2
[07:12] <Keybuk> it took well over an hour to install here
[07:12] <BenC> Keybuk: what's your host you've been testing with now?
[07:12] <Keybuk> ICH7
[07:13] <Keybuk> intel core duo
[07:13] <BenC> piix or ata_piix for disk?
[07:13] <BenC> I assume the latter
[07:13] <Keybuk> ata_piix
[07:13] <BenC> is a 1 hour install really that bad for a virtualized install?
[07:13] <mvo> here is another nvidia-glx releated error: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/106518/ (not sure we can/should do anything, seems to be caused by the "envy" tool
[07:14] <Keybuk> BenC: yes, given we've specifically press released that we have improved performance in vmware! :)
[07:14] <BenC> mvo: Nope, reject that one, we can't do anything about people clashing local installs with package installs
[07:14] <mvo> BenC: will do, thanks
[07:14] <BenC> Keybuk: how long does edgy take to install?
[07:14] <Keybuk> BenC: 10-15 mins max
[07:14] <pkl_> BenC: you said vmware is prime feature for Ubuntu Server 7.04... But, what vmhost host oses are you concerned with.  I was going to try vmware under MacOS X (in Beta), but if vmwarte host on Linus all you're concerned with, I won't bother.
[07:14] <BenC> I don't recall ever getting an install that fast
[07:15] <Keybuk> feisty took 60-90 mins (I got so bored I did other things)
[07:15] <Keybuk> BenC: I can appreciate that you can't replicate the problem
[07:15] <BenC> pkl_: we are promoting our guest speed, so any host should be good
[07:15] <Keybuk> so what can mdz do to help you understand it?
[07:15] <Keybuk> mdz and I
[07:15] <BenC> Keybuk: I can't replicate your 10-15 minutes installs with edgy is the problem :)
[07:15] <Keybuk> BenC: how long do they take for you?
[07:16] <BenC> Keybuk: and besides, our "speed feature" is only in relation to ws6 and related products where paravirt is enabled
[07:16] <BenC> Keybuk: about an hour
[07:17] <Keybuk> the press release doesn't say that :-/
[07:17] <BenC> the press release is quite lacking in information that I've provided then
[07:17] <Keybuk> what kind of VM did you use?
[07:17] <BenC> "Improved performance with as a guest under VMware using paravirtual ops"
[07:18] <BenC> Keybuk: I've been using ws6 for quite some time, in beta
[07:18] <Keybuk> this is 256MB / 8.0GB ide / CD-ROM bound to file / 2 processors
[07:18] <BenC> haven't used ws5 in awhile...I think I have edgy around here I can test on now that I have a ws5 install
[07:18] <Keybuk> didn't you just say you tested on ws5?
[07:18] <BenC> Keybuk: I did all default, so 256Meg, 8G, CDROM to file, single CPU
[07:19] <BenC> Keybuk: I just tested a feisty RC on ws5
[07:19] <Keybuk> and it booted in around 1m30?
[07:19] <Keybuk> with no noticeable lag drawing the desktop?
[07:19] <BenC> yep
[07:20] <Keybuk> weird
[07:20] <BenC> the install is 15 minutes in, and at around 47% copying files
[07:21] <BenC> ruh roh
[07:21] <BenC> power may be going
[07:22] <BenC> if I drop, it may be 20-30 minutes before I get gen up and running
[07:22] <BenC> Keybuk: let's get some info out here to compare why things are slow for you and mdz and not for me
[07:23] <BenC> mdz is running on a dapper host
[07:23] <BenC> mdz: what sort of machine is it?
[07:23] <BenC> video, hd, etc.
[07:23] <BenC> Keybuk: one thing I didn't do on my VM was setup networking...so that's a datapoint right now
[07:23] <BenC> Keybuk: have you tried single cpu yet?
[07:24] <BenC> for guest
[07:24] <Keybuk> doing a dapper install now
[07:24] <Keybuk> to test
[07:24] <Keybuk> yeah, single cpu was same problem
[07:24] <Keybuk> I tried double to see whether that fixed it
[07:25] <cjwatson> I'll give you a third data point at some point after dinner
[07:26] <BenC> is nvidia-glx-new on the CDs?
[07:29] <mdz> BenC: I've only been able to test on this dapper amd64 box
[07:29] <BenC> mdz: is it running 32-bit or 64-bit on host?
[07:29] <mdz> BenC: did you compare with beta, or with ws6?
[07:29] <BenC> and are you testing 32-bit or 64-bit guest?
[07:29] <Keybuk> 32-bit guest on 32-bit host for me
[07:29] <mdz> BenC: it's running a 32-bit kernel
[07:30] <mdz> 32-bit guest
[07:30] <Keybuk> (same problem seen with 32-bit guest on 64-bit host)
[07:30] <mdz> just happens to be a 64-bit cpu
[07:30] <BenC> I have 64-bit host, but 32-bit ws5 and 32-bit guest
[07:30] <BenC> so it _should_ be the same
[07:30] <Keybuk> I assume my 64-bit host was a 64-bit ws5, since it can host 64-bit images
[07:30] <BenC> mdz: can you really get 10-15 minute installs of edgy?
[07:30] <mdz> BenC: and were you able to measure a difference from beta->rc?
[07:30] <Keybuk> (how does one tell?)
[07:31] <Keybuk> BenC: I'm half way through a dapper install, 9m gone, 9 to go
[07:31] <mdz> BenC: I can do one right now and time it...
[07:32] <BenC> Keybuk: I think guest support is only limited by kernel/vmmon, so it might still be a 32-bit vmware
[07:32] <BenC> Keybuk: file /usr/local/bin/vmware
[07:32] <BenC> see if it's elf 32 or 64
[07:33] <BenC> let me get an edgy iso to see if I can get this super speed install
[07:33] <Keybuk> 54%, 6:08 remaining
[07:33] <mdz> (edgy boots the live CD in 1:07 fwiw)
[07:34] <Keybuk> /opt/vmware/vmware: Bourne shell script text executable

[07:34] <BenC> can you guys check your bogomips between edgy and feisty?
[07:34] <Keybuk> /opt/vmware/lib/bin/vmware: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
[07:34] <Keybuk> ok
[07:34] <Keybuk> BenC: inside vmware or outside?
[07:34] <BenC> Keybuk: ok, same as me then
[07:34] <BenC> Keybuk: in vmware
[07:34] <Keybuk> that's in dmesg right?
[07:35] <BenC> or /proc/cpuinfo
[07:35] <Keybuk> [   18.818982]  Calibrating delay using timer specific routine.. 2403.75 BogoMIPS (lpj=4807513)
[07:35] <Keybuk> ^ cupprent
[07:35] <Keybuk> [   49.406032]  Calibrating delay using timer specific routine.. 2380.15 BogoMIPS (lpj=4760307)
[07:35] <Keybuk> ^ beta
[07:35] <mdz> ubuntu@ubuntu:/mnt/var/log/installer$ sudo grep ubiquity syslog |head -1
[07:35] <mdz> Apr 12 13:11:25 ubuntu ubiquity[6131] : Ubiquity 1.2.5
[07:35] <mdz> ubuntu@ubuntu:/mnt/var/log/installer$ sudo grep ubiquity syslog |tail -1
[07:35] <mdz> Apr 12 13:27:11 ubuntu ubiquity: Purging configuration files for libglibmm-2.4-1c2a ...
[07:35] <mdz> ^^^ 6.10 final
[07:35] <Keybuk> [17179573.224000]  Calibrating delay using timer specific routine.. 2406.73 BogoM
[07:35] <Keybuk> IPS (lpj=4813470)
[07:35] <Keybuk> ^ dapper
[07:37] <mdz> ubuntu@ubuntu-desktop:/var/log/installer$ sudo grep ubiquity syslog |head -1
[07:37] <mdz> Apr 16 09:46:25 ubuntu ubiquity[8750] : Ubiquity 1.4.11
[07:37] <mdz> ubuntu@ubuntu-desktop:/var/log/installer$ sudo grep ubiquity syslog |grep glibmmApr 16 10:11:20 ubuntu ubiquity: Removing libglibmm-2.4-1c2a ...
[07:37] <mdz> ^^ current feisty
[07:38] <mdz> so 16 minutes vs.  25
[07:39] <BenC> mdz: so feisty took 25 minutes to install and edgy took 16?
[07:39] <mjg59> What's the difference on real hardware?
[07:40] <mdz> unknown, I just had those numbers around
[07:40] <mdz> the real difference I saw was between the 11th and 12th
[07:40] <mdz> both in vmware
[07:40] <mdz> unfortunately we've deleted those isos
[07:41] <BenC> mdz: was that perhaps when we went from piix to ata_piix?
[07:42] <mdz> BenC: yes
[07:42] <mdz> er
[07:42] <mdz> no, the other way around
[07:42] <mdz> from ata_piix to piix
[07:42] <Keybuk> dapper install finished: 21 mins
[07:42] <BenC> how could you notice a problem when ata_piix wasn't even working for you?
[07:43] <BenC> s/problem/slow down/
[07:43] <BenC> wasn't working for atapi at least
[07:43] <BenC> or did you notice a general problem in an existing system when we did the switch
[07:43] <BenC> existing VM that is
[07:46] <BenC> Ok, edgy iso booted in about the same amount of time for me
[07:47] <BenC> starting the install
[07:48] <BenC> wow, I think my guest clock just went backwards
[07:48] <Keybuk> they do that
[07:48] <BenC> I could have sworn I saw it go 1:48 to 1:47, then to 1:48 again
[07:48] <Keybuk> I like mdz's demo that sleep 10 sleeps for an amount of time that will never equal 10s
[07:48] <BenC> I'll watch the host clock
[07:48] <Keybuk> a watched clock never boils
[07:49] <BenC> hopefully, neither does an unwatched one :)
[07:51] <mdz> BenC: the clock is very funny, I don't really trust those numbers in syslog
[07:51] <mdz> BenC: ata_piix was functional for me, it just spewed a huge volume of scary errors while it worked
[07:51] <BenC> mdz: even for atapi it worked?
[07:51] <mdz> I'm open to the idea that Keybuk and I are both hallucinating
[07:51] <mdz> BenC: yes, I was only using it for atapi
[07:52] <BenC> hmm
[07:52] <mdz> I use the standard default ubuntu config in vmware, which is a SCSI (LSI) HDD and ATAPI (PIIX) CD-ROM
[07:52] <mdz> but while I'm open to the idea, someone needs to independently demonstrate that we're crazy
[07:52] <mdz> because so far our results are consistent with each other
[07:53] <BenC> my boot times for edgy/feisty under vmware are only off by a few seconds...they are virtually (heh) the same
[07:53] <BenC> the install times I'm checking now
[07:53] <Keybuk> which feisty?
[07:53] <mdz> BenC: booting the CD or booting from HDD?
[07:53] <BenC> latest ISO, 15.27 kernel
[07:54] <BenC> mdz: booting the live CDs
[07:54] <mdz> BenC: ok, that's very interesting
[07:54] <Keybuk> so, I'm trying a random test
[07:54] <BenC> this clock skew on vmware really worries me
[07:55] <Keybuk> booting different livecds and moving 8GB from a SCSI disk to an IDE disk and back again
[07:55] <BenC> it's already 6 minutes ahead of my host
[07:55] <mdz> BenC: I see that too, though I think I probably always have
[07:55] <BenC> mdz: I'd say the syslog times you pasted are probably bad data points for this
[07:56] <Keybuk> maybe vmware is going so fast, it's slowing down time
[07:56] <Keybuk> (and thus installs)
[07:56] <BenC> mdz: any chance you can do installs and check your host times for comparison?
[07:56] <mdz> BenC: I agree
[07:56] <mdz> but Scott's are wall clock timings
[07:56] <cjwatson> I'm going to do a test in a second
[07:56] <Keybuk> ie. I timed it with a stopwatch
[07:56] <cjwatson> however this is on a Debian host as I've never migrated that vmware install
[07:57] <mdz> cjwatson: my host has been neutral throughout; I don't suspect any problem on the host side
[07:57] <cjwatson> Keybuk: from pressing enter at the CD boot prompt, or from vmware boot?
[07:57] <BenC> cjwatson: hard to muddy the water any more than it is  :)
[07:57] <BenC> cjwatson: I did CD prompt to icons showing up
[07:57] <Keybuk> cjwatson: from pressing ^D at break=top after manually loading piix and making sure it was bound
[07:57] <cjwatson> FWIW, I'm on 5.5.1
[07:57] <BenC> Keybuk: on -15.27 kernel feisty, piix most certainly is bound
[07:58] <BenC> for beta iso's, you need the break
[07:59] <BenC> for installs, I'm timing from the last screen in ubiquity to the "restart" dialog
[08:00] <mdz> 5.5.2 build-29772 here
[08:00] <kylem> amd64?
[08:00] <mdz> and BenC's using my tarball
[08:00] <mdz> kylem: amd64 running 32-bit kernel/userland/guest
[08:00] <cjwatson> feisty boots in 1:28
[08:00] <kylem> sorry, i should say "athlon64"
[08:00] <kylem> i mean, is it an amd chip
[08:00] <mdz> yes
[08:00] <BenC> see, colin's getting what I'm getting for feisty
[08:01] <kylem> dual core amd has unsynched tsc.
[08:01] <mdz> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
[08:01] <cjwatson> will take a few minutes for edgy to copy across from my server
[08:01] <kylem> so if vmware is using the tsc to get the clock, it will flip back and forth and lose (or gain) ticks
[08:01] <BenC> mine is turion x2 as well
[08:01] <Keybuk> my vmware clock always runs slower than my host clock
[08:02] <cjwatson> mine is single-core Athlon64
[08:02] <Keybuk> and it's a dual-core Intel
[08:02] <cjwatson> fairly old, summer 2004 I think
[08:02] <BenC> Keybuk: weird, on this box, mine always runs faster :)
[08:02] <BenC> so Keybuk is the only one testing on an Intel host right now
[08:02] <kylem> hmm
[08:02] <BenC> but we have UP and SMP covered
[08:03] <BenC> ok, wall clock time on my edgy install was 15 minutes
[08:04] <cjwatson> that's from pressing Install button on summary page to final dialog appearing?
[08:04] <pkl_> Ubuntu in Parallels also runs slower than the host clock.
[08:05] <Keybuk> boot too
[08:05] <BenC> cjwatson: yes
[08:05] <cjwatson> (feisty took a weirdly large amount of time to get to usplash, btw - maybe 20 secs)
[08:05] <pkl_> which is Intel obviously.
[08:05] <cjwatson> edgy boots in 0:52
[08:06] <cjwatson> unfortunately I don't have feisty beta handy - will take c. 2 hours to download
[08:06] <BenC> so noticeably slower, but possibly due to more services?
[08:06] <cjwatson> kicked off a download
[08:06] <cjwatson> I think most of that was the pre-usplash delay
[08:07] <BenC> I need to do these boot tests on a real machine between edgy/feisty
[08:07] <cjwatson> which could easily have been something kooky in initramfs
[08:07] <BenC> unless someone else wants to do it
[08:07] <cjwatson> why don't I kill the beta download to avoid stray i/o and do install time tests
[08:07] <mdz> there's really no need to mess with edgy
[08:07] <mdz> the difference can be seen from beta->rc
[08:07] <BenC> I don't  have beta handy
[08:07] <cjwatson> yes, but I have edgy here and not beta
[08:07] <BenC> but I guess I can download it
[08:08] <cjwatson> the need to mess with edgy is getting results now instead of in two hours
[08:08] <mdz> but the results may not be particularly meaningful
[08:08] <cjwatson> absence of regressions from edgy is meaningful enough to me
[08:08] <Keybuk> mdz: ish, beta does take a long time to install for me :-/
[08:08] <Keybuk> edgy is worth testing
[08:09] <Keybuk> and is equally worthwhile
[08:09] <Keybuk> if we can get a definitely reproducible useful test, we can track forward
[08:09] <Keybuk> more than "boot time"/"install time"
[08:09] <cjwatson> anyone tried bonnie++ or similar?
[08:10] <cjwatson> pre-usplash delay> oh, I bet that's console-setup
[08:11] <Keybuk> BenC: interesting timing here
[08:11] <cjwatson> though it should be working with pregenerated files
[08:11] <Keybuk> hdparm -t on an IDE disk in vmware
[08:11] <Keybuk> dapper: 1800 MB/s
[08:11] <cjwatson> so I don't quite get why it would be so slow
[08:11] <Keybuk> current: 750 MB/s
[08:11] <BenC> oooh
[08:12] <BenC> Keybuk: is it reproducible many times?
[08:12] <Keybuk> yes
[08:12] <Keybuk> the numbers are pretty consistent
[08:12] <BenC> worry about the guest clock skewing things
[08:12] <mjg59> hdparm -T is probably more realistic
[08:12] <Keybuk> yeah, given the guest clock skew, that's unconfirmed
[08:13] <cjwatson> -T doesn't measure throughput to the disk though?
[08:13] <Keybuk> mjg59: 75 MB/s vs. 35 MB/s
[08:13] <cjwatson> it's a more realistic system test, but the disk controller driver is the suspect component here ...
[08:13] <mdz> cjwatson: it's been difficult to do benchmarking inside the VM because the clock is fucked
[08:14] <BenC> there's gotta be a way to do this
[08:14] <cjwatson> something that took a stopwatch-measurable amount of time to do each test would be good enough
[08:14] <BenC> vmware was doing micro and macro benchmarks reliably
[08:14] <mjg59> cjwatson: -t is also testing the vm system
[08:14] <Mithrandir> cjwatson: for i in `seq 20`; do dd if=/dev/hda; done and using a stopwatch should work.
[08:14] <Keybuk> mjg59: "performance problems in vmware" could also be the vm system, though I doubt it
[08:15] <cjwatson> -T does buffer cache which doesn't seem especially useful or relevant
[08:15] <Keybuk> Mithrandir: dd to where?
[08:15] <Mithrandir> Keybuk: /dev/null?
[08:15] <cjwatson> in particular it explicitly says "without disk access"
[08:15] <mjg59> Oh, sorry - I had those the wrong way round
[08:16] <mjg59> Though the timings would seem more consistent with them being the way I thought...
[08:16] <cjwatson> mm
[08:17] <mdz> cjwatson: I believe that means 'without physical disk reads' not 'without communicating with the disk'
[08:17] <mdz> oh, I'm wrong
[08:17] <cjwatson> mdz: in context, it's talking about buffer cache and says it deliberately avoids measuring disk performance
[08:17] <mdz> "This displays the speed of reading directly from the Linux buffer cache without disk access."
[08:18] <cjwatson> comparison from my laptop:
[08:18] <cjwatson>  Timing cached reads:   814 MB in  2.00 seconds = 406.48 MB/sec
[08:18] <cjwatson>  Timing buffered disk reads:   84 MB in  3.01 seconds =  27.89 MB/sec
[08:18] <kylem> that would make sense.
[08:19] <cjwatson> edgy installs in <9:47 (I wasn't looking at the screen and that's when I noticed; it wasn't much less)
[08:19] <Keybuk> Mithrandir: 3:41.1 in feisty current
[08:19] <Mithrandir> Keybuk: ugh.
[08:19] <Keybuk> oddly enough, vmware's clock matches stopwatch there
[08:19] <Mithrandir> hmm
[08:19] <cjwatson> Keybuk: how big a disk?
[08:20] <Keybuk> 8GB
[08:20] <cjwatson> oh, and fragmented or solid?
[08:20] <cjwatson> (whatever you call the non-fragmented thing - single-file?)
[08:20] <Keybuk> 2GB chunks
[08:20] <Mithrandir> preallocated?
[08:20] <cjwatson> yeah
[08:20] <Keybuk> not actually allocated though
[08:20] <Keybuk> since the disk is "empty"
[08:20] <Keybuk> so this shouldn't touch the host disk hardly at all
[08:20] <cjwatson> I have limited disk space so I always use chunks
[08:24] <BenC> feisty install is definitely noticeably slow for me than edgy
[08:24] <BenC> 12 minutes into it, and it's only at 50%, still copying files
[08:24] <cjwatson> will tell you my result there in a moment
[08:24] <BenC> guess I better get beta
[08:25] <BenC> mdz, Keybuk: so beta was ok, and current is slow, that's your test case right now?
[08:25] <Keybuk> BenC: I have my doubts about beta
[08:25] <Keybuk> current is definitely slow
[08:25] <BenC> ah, right, beta was still slow for you
[08:25] <mdz> I don't get consistent results from hdparm at all, which is unsurprising to me given the clock skew
[08:26] <mdz> BenC: beta is better here
[08:26] <Keybuk> wall time on dapper for the dd test, 02:39
[08:26] <mdz> I installed dailies in vmware all last week, and noticed the difference on thursday
[08:26] <mdz> but I am at a loss to provide particularly believable numbers
[08:27] <BenC> mdz: do you have the same dailies around?
[08:27] <mdz> BenC: nope
[08:27] <mdz> they were deleted over the weekend, while I was dealing with my hosed laptop
[08:28] <BenC> mdz: given a kernel image just before the ata_piix/piix switch, can you regen an ISO from current using that image?
[08:28] <mdz> BenC: that should be possible, yes
[08:28] <kylem> http://www.vmware.com/vmtn/resources/238
[08:29] <BenC> 14.22 was just before the switch
[08:31] <BenC> damnit, the .deb's are gone from lp
[08:31] <cjwatson> err, shouldn't be
[08:31] <kylem> for the broken one they were nuked, no?
[08:31] <cjwatson> I'll find them
[08:31] <cjwatson> not from the librarian, no
[08:31] <kylem> ah.
[08:31] <cjwatson> they're just hard to find
[08:32] <cjwatson> you have to go to the "builds of" portlet
[08:32] <cjwatson> http://librarian.launchpad.net/7122345/linux-image-2.6.20-14-generic_2.6.20-14.22_i386.deb
[08:32] <BenC> great, ws5 killed my other box now
[08:32] <BenC> flashing led's
[08:32] <cjwatson> feisty installs in 8:44 (I think, pressed the wrong stopwatch button)
[08:33] <BenC> a lot faster than mine
[08:33] <cjwatson> not willing to say it's definitely faster than edgy, but given the lack of attention in my experiment it's definitely within experimental error
[08:34] <cjwatson> I'll try the dd test with fresh disks in a moment
[08:35] <mdz> BenC: they still seem to be there to me: https://launchpad.net/+builds/+build/315769
[08:36] <cjwatson> I think Ben was following the links from linux-source-2.6.20/2.6.20-14.22 to the individual binaries rather than to the builds
[08:36] <BenC> yeah
[08:39] <BenC> anyone have the piix dev id for vmware handy?
[08:39] <cjwatson> Keybuk: how many dd iterations was your 3:41.1 timing above?
[08:39] <cjwatson> BenC: 8086:7111
[08:39] <BenC> thanks
[08:40] <kylem> 06:31 < mdz> http://people.ubuntu.com/~mdz/temp/lspci-vmware
[08:40] <kylem> BenC, you'll want subvendor/subdevice too if you're going to blacklist it from one of the modules.
[08:41] <BenC> force probing ata_piix with new_id
[08:41] <Keybuk> cjwatson: just one
[08:41] <BenC> see if the install is any faster
[08:43] <cjwatson> about 2:50 for the dd test, 50.6 MB/s according to vmware's clock which seems more or less right
[08:43] <cjwatson> Keybuk: did you try dd from the cdrom?
[08:44] <Keybuk> cjwatson: that's what I'm trying now
[08:44] <Keybuk> still waiting for current to boot
[08:45] <cjwatson> 'cos my timing is not all that far off yours
[08:45] <heno> FWIW, I just did a virtualbox install here that too 11 minutes total, the CD-HD copying phase was just 7 minutes; will do Edgy next
[08:46] <cjwatson> feisty dd if=/dev/hdc of=/dev/null: 33 seconds
[08:46] <Keybuk> 1430344+0 records in
[08:46] <Keybuk> 1430344+0 records out
[08:46] <Keybuk> 732336128 bytes (732 MB) copied, 115.963 seconds, 6.3 MB/s
[08:47] <Keybuk> (hdc -> null on dapper, 5x that one's pretty representative, there wasn't much deviation)
[08:47] <cjwatson> quite a lot slower
[08:47] <cjwatson> oh, dapper? hmm
[08:47] <cjwatson> unused to your machine just sucking compared to mine ;-)
[08:47] <Keybuk> it's only a laptop
[08:47] <cjwatson> ah
[08:48] <cjwatson> thought it was the 10-second booter or whatever it was
[08:48] <Keybuk> nah, that's at home
[08:48] <Keybuk> far too heavy to lug on skates
[08:50] <cjwatson> edgy dd hda: 1:23, twice as fast as feisty
[08:50] <mdz> cjwatson: wallclock time?
[08:50] <cjwatson> yes
[08:50] <Keybuk> I must admit, that my wall clock and my vmware clock match
[08:50] <cjwatson> mine too
[08:50] <mdz> Keybuk: you're uniprocessor
[08:50] <Keybuk> I've worked out why vmware's clock is different, it ran ntpdate ;)
[08:50] <mdz> both of you are
[08:50] <Keybuk> mdz: dual core
[08:50] <Keybuk> just intel not amd
[08:51] <cjwatson> edgy dd hdc: 28 seconds, smidge faster than feisty
[08:51] <cjwatson> that explains why install tests showed no difference, the CD hasn't changed much
[08:51] <Keybuk> ok, that was interesting
[08:51] <Keybuk> let me just repeat that test before I say about it
[08:52] <cjwatson> mm, I'm going to repeat my dd tests too
[08:54] <Keybuk> I just stopped bothering
[08:54] <Keybuk> and then noticed something
[08:54] <Keybuk> in feisty my wall clocks *are* different to vmware's clocks
[08:55] <Keybuk> in dapper they matched
[08:55] <BenC> bah, ata_piix doesn't support hotplug of controllers
[08:55] <BenC> wish there was a way to atomically add new_id during module init
[08:57] <Keybuk> hmm, dd giving comparable results for me too
[09:00] <heno> complete Edgy install on virtualbox: ~7.5 minutes, the CD->HC copying phase less than 5 minutes. So Edgy is significantly faster than Feisty on virtualbox too
[09:01] <BenC> heno: what's the time for feisty on vbox?
[09:01] <dholbach> BenC: <heno> FWIW, I just did a virtualbox install here that too 11 minutes total, the CD-HD copying phase was just 7 minutes; will do Edgy next
[09:01] <BenC> those times can be accounted for by things other than a kernel bug, I think
[09:02] <BenC> interesting, but still inconclusive
[09:02] <mdz> heno: which driver is used for the CD-ROM there?
[09:02] <BenC> heno: thanks for the testing
[09:02] <BenC> IIRC, it's piix as well, probably same 8086:7111
[09:03] <BenC> is it at all possible that these times could be squashfs related?
[09:03] <heno> mdz: can you tell me how to find out?
[09:03] <mdz> heno: lspci -vvnn | grep IDE
[09:04] <mdz> BenC: the squashfs update was much earlier, no?
[09:04] <mdz> pkl_: any reasonable potential for a performance regression there?
[09:06] <pkl_> the squashfs update was checked in on 16th Mar.  It doesn't appear in the debian/changelog and so I don't know what daily first had it.
[09:07] <BenC> how can it not show in the changelog?
[09:07] <BenC> it's automated :)
[09:09] <BenC> that's odd
[09:09] <BenC> if we go by dates, then it had to be either in -12.19 or -12.20
[09:10] <Mithrandir> you don't have it tagged in git?
[09:10] <cjwatson> (speaking of which, can we lose the GIT-SHA lines from debian/changelog in gutsy? anyone who needs them can get them from git log)
[09:10] <mdz> BenC: it's not there
[09:10] <mdz> cjwatson++
[09:10] <cjwatson> commit 01c7ecb34704df7feae2532006169786642f8fdd
[09:10] <cjwatson> Author: Phillip Lougher <phillip@gandalf.(none)>
[09:10] <cjwatson> Date:   Fri Mar 16 14:02:58 2007 +0000
[09:10] <cjwatson> UBUNTU: Squashfs: update to 3.2-r2
[09:10] <cjwatson> Signed-off-by: Phillip Lougher<EMAIL_ADDRESS>[09:10] <mdz> makes it much harder to scan the changelog
[09:11] <BenC> yes, I can that :)
[09:11] <Keybuk> ok, interesting
[09:11] <cjwatson> <cjwatson@cairhien ~/src/ubuntu/linux/ubuntu-feisty>$ gzip -9c debian/changelog | wc -c
[09:11] <cjwatson> 79301
[09:11] <cjwatson> (also)
[09:11] <cjwatson> <cjwatson@cairhien ~/src/ubuntu/linux/ubuntu-feisty>$ grep -v GIT-SHA debian/changelog | gzip -9c | wc -c
[09:11] <cjwatson> 63093
[09:11] <Keybuk> dd if=/dev/hdc of=/dev/sda1, wall time was 11:50, clock time was 543s
[09:11] <BenC> It was in -12.19
[09:12] <pkl_> Grep the changelog for Squashfs... first entry 26 Oct 2006
[09:12] <cjwatson> and yet the tree clearly shows that the diff is applied
[09:12] <BenC> pkl_: I'm not sure how it got left out of the changelog, but it was definitely in the 2.6.20-12.19 upload
[09:13] <BenC> git-log Ubuntu-2.6.20-11.18..Ubuntu-2.6.20-12.19
[09:13] <BenC> shows it
[09:13] <heno> mdz oddly lspci -vvnn didn't give me that info, but Device Manager tells me PIIX_IDE
[09:14] <BenC> it would be nice if there was a quick way to see what kernels were in what milestone
[09:15] <cjwatson> BenC: is it possible the scripts didn't like Phillip's (none) hostname?
[09:15] <cjwatson> although later changes from pkl do show up
[09:15] <BenC> cjwatson: it should never drop any changes...all "unknown" ones that don't parse as an ubuntu change should show up under "Upstream Changes:
[09:16] <pkl_> cjwatson: previous commits show up, even though the hostname had the same problems.  But, I noticed the none hostname and fixed that.
[09:17] <heno> we should do some timings of copying the content of an entire alternate ISO to the HD in Edgy and Feisty (in vmware) to isolate CD driver vs. sqashfs issues
[09:18] <BenC> git-log  --pretty=short Ubuntu-2.6.20-11.18..Ubuntu-2.6.20-12.19 | perl -w -f debian/bin/git-ubuntu-log
[09:18] <BenC> cjwatson: that command misses his entry, so I'll have to check why
[09:19] <pkl_> Squashfs 3.2-r2 does have some performance improvements over Squashfs 3.1 in the main data-path.  None of the changes should have caused problems (quite the opposite).
[09:20] <pkl_> I'll have a look at the code...  It's probably worth pointing out Squashfs 3.2-r2 was released in January, and no-one else has reported any speed regressions (such a major drop in performance would be immediately noticed by quite a number of liveCDs).
[09:22] <cjwatson> yeah, I think chances are thet squashfs is a red herring myself
[09:22] <cjwatson> that
[09:23] <BenC> pkl_: we're having problems pointing the finger at anything, so squashfs got dragged in
[09:23] <BenC> pkl_: is there an easy test we can do from livecd to see squasfs performance comparisons?
[09:24] <BenC> like find /usr | time xargs cat > /dev/null ?
[09:24] <pkl_> Ah, I don't mind.  Squashfs is an obvious candidate, and I've been trying to think of potential issues all day :)
[09:24] <pkl_> Yes, there's two potential cases.  Dentry performance is slower, or readpage performance is slower... or both.
[09:25] <pkl_> Doing a find with an option requiring a stat of each inode (i,e, -type f), will test dentry regressions.
[09:25] <cjwatson> find | xargs has the problem that it also stresses CD seek times
[09:25] <cjwatson> might not matter in vmware of course
[09:26] <BenC> only a virtualized ISO, probably not much of an issue
[09:26] <cjwatson> maybe read a big file out of the squashfs instead
[09:26] <pkl_> All the metadata is packed together at the end of the disk...  Just doing metadata operations (no file reads) will not seek the head too much.
[09:27] <pkl_> no file data reads, that is.
[09:27] <cjwatson> biggest file on the squashfs is /usr/lib/libgcj.so.70.0.0 - only 30MB though
[09:27] <cjwatson> ("only". damn gcj.)
[09:27] <BenC> I keep thinking we need a sane way to go back and forth between piix and ata_piix using the same CD
[09:27] <Keybuk> doesn't openoffice have one bigger?
[09:28] <cjwatson> this is from "find /rofs -type f -printf '%p %s\n' | sort -k2 -nr | head"
[09:28] <cjwatson> so no
[09:28] <BenC> ata_piix doesn't support new_id
[09:28] <BenC> piix does though
[09:28] <cjwatson> OOo doesn't come in until no. 7
[09:28] <BenC> I'm going to build a 2.6.20-15.27 that defaults to ata_piix, and we can override it easily to piix
[09:29] <cjwatson> TBH, this is all pressing my "release-critical" buttons less and less convincingly
[09:30] <mdz> cjwatson: agreed
[09:30] <cjwatson> though I think it is still worth the detailed investigation
[09:30] <cjwatson> I'm just a bit worried that we're focusing so much on this that we may not be paying attention to other testing information coming in
[09:30] <cjwatson> anyway, speaking of focusing, it's 8:30pm and I'm off to play Lego Star Wars or something :)
[09:31] <Keybuk> heh
[09:31] <pkl_> Doing a large file read will test readpage regressions.  There's three major changes between Squashfs 3.1 and Squashfs 3.2-r2.  Once affects dentries only, one affects dentries and readpage, and one only affects readpage.  If it was Squashfs, it would be uselful to isolate it.
[09:31] <cjwatson> pkl_: is 30MB likely to be large enough, or would we need a custom squashfs?
[09:32] <BenC> cjwatson, mdz: I do need to make an lrm upload to fix nvidia-glx-new
[09:32] <cjwatson> dd tells me 27.2 MB/s first time round, and thereafter c. 200
[09:32] <BenC> It doesn't affect linux-restricted-modules-* at all
[09:32] <pkl_> I'm not sure, but looking at the slowdown, it should be measurable over 30MB.
[09:32] <cjwatson> (feisty
[09:32] <cjwatson> )
[09:32] <BenC> just that one package (so doesn't bother CDs)
[09:33] <BenC> pkl_: given vmware's clock fuckage, it may not be enough to be reliable :/
[09:33] <pkl_> Yeah, that's why I abandoned Parallels and Vmware for Squashfs development.
[09:34] <pkl_> Couldn't reliably tell why affect changes had made ....
[09:34] <pkl_> why -> what
[09:37] <BenC> I would be interested in why my laptop is crashing with ws5 and ws6 though
[09:37] <mdz> BenC: beg pardon?
[09:37] <mdz> BenC: what's wrong with it?
[09:38] <BenC> mdz: nvidia-glx-new is missing a file that wasn't in the other versions of nvidia
[09:38] <BenC> xorg module
[09:38] <mdz> BenC: so it's non-functional?
[09:39] <mdz> sounds like an SRU candidate if so
[09:39] <Mithrandir> BenC: isn't nvidia-glx-new on the CDs?
[09:39] <BenC> I don't know if nvidia-glx* is on the CDs
[09:39] <BenC> I didn't think they were
[09:39] <BenC> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/103050
[09:39] <BenC> there's the bug
[09:39] <Mithrandir>   Adding nvidia-glx to CD 1 ...
[09:40] <Mithrandir> not -new, it seems, though
[09:40] <cjwatson> nvidia-glx is explicitly seeded, but not -new
[09:40] <BenC> is -legacy?
[09:40] <mdz> not an issue for installs or upgrades -> -updates
[09:40] <cjwatson> -legacy was deliberately unseeded at one point
[09:40] <Mithrandir> BenC: doesn't look like it, no.
[09:40] <Mithrandir> cjwatson: because we can't even pretend to give security support for it.
[09:40] <Mithrandir> AIUI
[09:40] <cjwatson> indeed
[09:41] <cjwatson> supported: * Extra-Exclude: nvidia-glx-legacy-dev # nvidia-glx-legacy is unsupportable
[09:41] <BenC> we can't for nvidial-glx{,-new} either :)
[09:41] <Mithrandir> we should probably invent a better name for nvidia-glx now that the package isn't maintained any more either. :-/
[09:41] <Mithrandir> BenC: we can pretend for -new
[09:41] <BenC> according to ATI it is
[09:41] <BenC> at least that
[09:41] <BenC> 's what they keep posting on the forums
[09:41] <Mithrandir> uh, ATI?  You mean nvidia?
[09:41] <mdz> I'm going to find food and then go home
[09:41] <BenC> err, I mean nvidia, yes :)
[09:42] <mdz> I have a functional laptop now though, so I should be back
[09:42] <Mithrandir> I'd be very surprised if ATI supported nvidia-glx. :-P
[09:42] <BenC> mdz: have a good evening
[09:42] <BenC> hehe
[09:42] <BenC> Mithrandir: well, my stink raised all kinds of responses from nvidia, basically saying "of course this package that isn't on our main download page is going to be supported"
[09:42] <Mithrandir> BenC: but, sure -new is fine since it doesn't touch the CDs.
[09:42] <BenC> though I've seen no indication other than hot air
[09:43] <BenC> Ok, upload should be quick and painless
[09:43] <cjwatson> Mithrandir: an l-r-m upload would create skew though
[09:43] <Mithrandir> cjwatson: ugh, true. :-/
[09:43] <Mithrandir> BenC: iirc -legacy at least has known root holes?
[09:43] <cjwatson> if that concerns you for update-manager ...
[09:43] <zdzichuBG> vmware-tools should mitigate clock skew
[09:43] <Mithrandir> cjwatson: it does.
[09:43] <Mithrandir> but if want to respin anyway..
[09:44] <cjwatson> I think I'm with mdz if it doesn't affect new installs or upgrades from dapper/edgy
[09:44] <BenC> Mithrandir: I don't think so anymore...although they have been release non-frequent updates to that line of the driver
[09:44] <Mithrandir> BenC: ok
[09:44] <BenC> cjwatson: which way is that, SRU?
[09:44] <cjwatson> yeah
[09:44] <Mithrandir> cjwatson: what about the update-manager one?
[09:44] <BenC> works for me
[09:45] <cjwatson> Mithrandir: no opinion yet, haven't read enough of it
[09:45] <cjwatson> BenC: if so, the bug should be milestoned later so we don't forget
[09:45] <Mithrandir> ok, tell me if you need anything for it.
[09:45] <cjwatson> er, "later"
[09:45] <Mithrandir> which is an edgy milestone.  LP should grow the ability to either move milestones between releases or have distro-wide milestones.
[09:45] <BenC> We have one Ubuntu:later
[09:45] <BenC> is that edgy?
[09:45] <Mithrandir> yes, but just use that one.
[09:46] <BenC> ok, done
[09:46] <Mithrandir> only LP cares that it's edgy.
[10:01] <heno> Copying the contents of an alternate CD to HD (virtualbox) on Edgy: 1:15, on Feisty: 1:10
[10:01] <heno> so if anything, slightly better CD performance of Feisty
[10:12] <BenC> heno: Contents as opposed to dd'ing the device image, right?
[10:12] <heno> BenC: right, nautilus copy+paste
[10:13] <BenC> sounds reasonably close then
[10:27] <Mirrado> Hi, where is the write place to submit a error with the last proposal to final version of the Feisty kernel?
[10:27] <mjg59> Mirrado: launchpad.net/bugs
[10:30] <Mirrado> I already created the bug in launchpad (bug #75935). That is enough?
[10:30] <mjg59> Yes
[10:30] <Mirrado> mjg59: thanks
[11:00] <cypherdelic> feisty wont beat 2.6.21, right?
[11:00] <mjg59> Feisty will be shipping 2.6.20
[11:01] <cypherdelic> so 2.6.21 will never be available for feisty?
[11:03] <MrNOKIA> i'm sure you'll find a tutorial on ubuntuforums to get a running .21 kernel pretty soon
[11:03] <MrNOKIA> so that would'nt be an issue
[11:03] <mjg59> We'll probably be skipping to .22 for gutsy
[11:04] <MrNOKIA> right
[11:04] <MrNOKIA> i meant untill gutsy kicks the shelves :)
[11:04] <cypherdelic> yes that would best, 6 month, hmm maybe ,23
[11:04] <mjg59> .23 is unlikely
[11:04] <mjg59> Given that .21 isn't out yet
[11:05] <cypherdelic> its rc7, torvalds doesnt want a rc7
[11:05] <cypherdelic> its nearly released
[11:12] <MrNOKIA> it might be nearly released
[11:12] <MrNOKIA> but it's not tested enough to get to a stable april release, IMO
[11:13] <BenC> 99% chance we'll be .22
[11:13] <MrNOKIA> that's why i said it could catch a nice compilation tutorial on the forums
[11:13] <BenC> 0.05% chance of .23, and 0.05% chance of .21
[11:14] <mjg59> BenC: Dude, that's 99.1%
[11:14] <MrNOKIA> BenC, so you're saying another kernel update is upon us ?
[11:14] <BenC> ok, 0.9% that we'll move to a hurd kernel
[11:15] <mjg59> MrNOKIA: For gutsy
[11:15] <BenC> MrNOKIA: for feisty, there are no more kernels
[11:15] <mjg59> Well, other than updates
[11:15] <BenC> except for security and maybe some driver updates
[11:15] <MrNOKIA> i was pretty sure of that :)
[11:16] <MrNOKIA> it seems there's an (minor ? ) issue with ati detection on the RC, according to the thread
[11:17] <cjwatson> what thread?
[11:17] <cypherdelic> yes yes more nvidia bug fixes
[11:17] <BenC> mjg59: looks like most of the ide/libata crack we have in feisty is upstream, except for libata-hpa...that look right to you?
[11:17] <MrNOKIA> http://ubuntuforums.org/showthread.php?p=2464356#post2464356
[11:17] <MrNOKIA> post #12
[11:17] <mjg59> BenC: And the ACPI stuff, but yes
[11:18] <BenC> mjg59: the "extended" acpi...
[11:18] <BenC> for just libata...ide-acpi is all good?
[11:19] <mjg59> Yeah
[11:19] <BenC> MrNOKIA: almost no info there...don't know if he's using ati or fglrx
[11:19] <cjwatson> don't know how it breaks either
[11:20] <BenC> likely not a kernel bug, so my stress level is constant (still high, but level)
[11:21] <BenC> cjwatson: I know rtg had some weird ati bug with the dell 1505 he has
[11:21] <rtg_> cjwatson: Still do.
[11:21] <BenC> install wouldn't work even for vesa graphics on the livecd, but after an install with alternate it went ok
[11:21] <BenC> rtg_: was yours a 200M?
[11:21] <rtg_> BenC: Not true. I had to install fglrx.
[11:22] <BenC> ah, that's right
[11:22] <rtg_> ATI X1300
[11:22] <BenC> we killed colin
[11:22] <rtg_> poor guy.
[11:22] <MrNOKIA> :)
[11:23] <MrNOKIA> there's one thing i don't get
[11:24] <MrNOKIA> are there instances where it might work beryl on a live cd ?
[11:24] <BenC> 945/965 graphics will work out of the box...some older ati cards work with xorg driver
[11:24] <MrNOKIA> i try to understand why it has been included on the livecd
[11:24] <MrNOKIA> mine is ati x1400 on my laptop
[11:25] <MrNOKIA> it doesn't work at all
[11:25] <BenC> "some older ati cards"
[11:25] <MrNOKIA> same for an nvidia 5500 card
[11:25] <MrNOKIA> i got it
[11:25] <BenC> obviously most laptops wont work
[11:25] <BenC> a lot of mine do, because I've preferred intel graphics lately
[11:26] <BenC> I don't get 23 billion fps with glx gears, but it runs nicely :)
[11:27] <MrNOKIA> i found my dell to be a best buy when it appeares
[11:27] <MrNOKIA> appeared
[11:27] <MrNOKIA> the only issue is the ATI card
[11:27] <BenC> if I buy anything right now, it's going to be core2duo with intel graphics
[11:27] <BenC> ipw3945 wireless
[11:28] <BenC> best platform for open source right now...only drawback is the ipw3945d userspace daemon
[11:28] <MrNOKIA> but i hope someday ATI will realize tha it has to consider linux
[11:28] <MrNOKIA> have a friend who worked there in the driver departament
[11:28] <MrNOKIA> he says linux doesn't matter for them very much :(
[11:29] <BenC> doesn't matter what the driver guys want...it's who's buying the cards that matters
[11:29] <MrNOKIA> i know...
[11:30] <BenC> I don't think ATI's going to come out well in the graphics area unless they start making some sweeping changes in how they handle their dwindling market share
[11:31] <MrNOKIA> maybe AMD will have a say in the matter
[11:31] <MrNOKIA> let's hope for the best :)
[12:03] <MrNOKIA> it seems there's more kernel trouble on reiserfs
[12:03] <MrNOKIA> here http://ubuntuforums.org/showthread.php?p=2464356#post2464356
[12:04] <MrNOKIA> what output could be helpfull in this situation ?


[03:27] <valorie> right, you've been out and about while I've been busy with genealogy and my societies
 I do remember meeting popey for the first time at LFNW :D
 I also met him again at Ubuntu Summit 2023, when I was actually old enough to buy him a drink hah
 Simon buying beers? Never! He's a kid forever like Jose.
 I'm a kid from Wisconsin ;)


[16:32] <dkessel> so thunar still randomly crashes on file renames.... meh
[16:32] <dkessel> i thought that might have been fixed in the meantime
[17:24] <bluesabre> dkessel: yeah, its better than it was, but still often enough to be a headache
[17:25] <dkessel> bluesabre: would it not be possible to install some kind of error handler to help pin down the cause of this?
[17:26] <bluesabre> dkessel: potentially one could run thunar with valgrind to try to find it, but since it doesn't happen everytime, could be a pain to figure it out
[17:27] <dkessel> bluesabre: oh, i can reproduce it fairly often
[17:27] <dkessel> it is just that i haven't been renaming folders often lately, which is why it hasn't happened during the last weeks
[17:29] <bluesabre> gotcha
[17:30] <bluesabre> install valgrind and run thunar with it.  Get it to crash and save the output to a file with the bug report, might help
[17:31] <dkessel> ok, will try
[17:45] <Unit193> bluesabre: Maybe more gdb?
[17:45] <Unit193> Or install -dbg and let apport do it?
[17:45] <bluesabre> Unit193: potentially
[17:45] <bluesabre> gdb is a pain for all though
[17:46] <bluesabre> :D
[17:49] <dkessel> Unit193: i got the -dbg package, but apport doesn't detect the end of the child process as crash
[17:49] <dkessel> mhh i am getting this while copying/files sometimes: http://paste.ubuntu.com/13071572/
[17:51] <dkessel> also, something seems to be with thumbnailing: http://paste.ubuntu.com/13071670/
[17:52] <dkessel> i don't know if any of these could sometimes cause the child process to crash/end
[17:55] <dkessel> oh, now i got it
[18:01] <dkessel> i got a trace in the moment of the crash. created bug 1512120
[18:02] <knome> dkessel, fwiw, duplicating the app name in the bug title isn't unwelcome
[18:03] <dkessel> knome: oh, ok in fact i believed it might be. np, fixing that
[18:03] <knome> it helps when it's there when linking to it externally (package/app name isn't always visible)
[18:03] <dkessel> ok i see.
[18:03] <knome> (including the status tracker... :P)
[18:04] <knome> np, continue
[18:04] <knome> :)
[18:18] <bluesabre> dkessel: cool, that looks like a good indicator of where the issue might be starting :)
[18:18] <bluesabre> suppose I'll start learning thunar's codebase now
[18:18] <bluesabre> :)
[18:19]  * bluesabre sets up xenial dev env and goes shopping
[18:19] <bluesabre> bbabl
[18:20] <dkessel> bluesabre: note that i my stack traces are from wily though. but it guess there should be no difference yet
[18:21] <bluesabre> dkessel: np, its been crashing since at least vivid
[18:22] <dkessel> alright. happy shopping
[20:46] <flocculant> oh boo - hating bzr
[20:46] <Unit193> That's usual, anything specific?
[20:47] <flocculant> merged the xubuntu-docs stuff cos of the changes there
[20:47] <flocculant> now got a bzr conflict with desktop-guide/libs/xubuntu.ent
[20:47] <knome> :Ð
[20:48] <knome> flocculant, sorry, i needed to poke it..
[20:48] <flocculant> yep
[20:48] <flocculant> knome: so how can I deal with this then?
[20:48] <knome> Unit193, krytarik: there's some work for you in the docs branch, the translation process isn't completely supporting two docbook sets yet
[20:49] <knome> xubuntu.ent should not exist any more...
[20:49] <knome> enduser doc related stuff should be in xubuntu-docs.ent
[20:49] <knome> in the same directory
[20:50] <knome> basically bzr expects you to get rid of all the .THIS .THAT .OTHER and whatever files
[20:51] <flocculant> still conflicts apparently
[20:51] <flocculant> can't be bothered to fight this
[20:51] <krytarik> knome: Is this the proper time for me to refer to '- contributor-docs/Makefile: "ln -s ../libs-common ../build/contributor-docs/libs-common" seems unnecessary', first? :P
[20:52] <Unit193> http://xkcd.org/1597/ mostly applies here.
[20:52] <flocculant> funnily enough ...
[20:54] <knome> krytarik, how is it?
[20:54] <knome> flocculant, if it's just about getting your MP rebased with the new stuff, don't bother
[20:54] <knome> flocculant, we'll handle that
[20:54] <flocculant> oh my lord
[20:54] <flocculant> still got problems :|
[20:55] <knome> flocculant, did you run "bzr resolve" ?
[20:55] <flocculant> why would I do that?
[20:55] <knome> flocculant, that checks if you have resolved the stuff in question
[20:55] <flocculant> you might know all these commands - but I don't ;)
[20:55] <knome> heh, sure
[20:55] <knome> that's why i ask
[20:55] <flocculant> knome: I grabbed anew - then copied my local stuff in to the new copy
[20:56] <knome> flocculant, mhm
[20:56] <flocculant> bzr resolve
[20:56] <flocculant> All conflicts resolved.
[20:56] <flocculant> bzr: ERROR: These branches have diverged.
[20:56] <flocculant> how can that be - if I *just* grabbed it
[20:57] <knome> flocculant, if you grabbed the new stuff, and then applied yours, they can be diverged because you have files that the new branch doesn't
[20:58] <flocculant> knome: I copied my changes into the new branch - not added anything that's not there, unless you removed doc pages
[20:59] <flocculant> knome: any reason not to delete branch lp:~flocculant/xubuntu-...
[20:59] <flocculant> and push it again?
[21:00] <flocculant> drc> [14:37:50] All I really care about is "what do they want me to put in the "hardware profile" of the test cases"  If Dell 1420n is enough, I'm good.
[21:00] <flocculant> I'm happy with whatever you want to put there - I'm not bothered about all that gist stuff at all
[21:04] <knome> flocculant, you can just push it again :)
[21:04] <flocculant> no I can't
[21:04] <flocculant> I get errors
[21:05] <Unit193> --overwrite
[21:06] <flocculant> Unit193: thanks - hopefully that got it :D
[21:06] <Unit193> That or it broke everything. :D
[21:06] <knome> flocculant, so was this about the changes you did?
[21:06] <knome> flocculant, or something new?
[21:07] <flocculant> knome: I appear to have pushed something now ;)
[21:08] <knome> ;)
[21:08] <flocculant> all manner of things happening in https://code.launchpad.net/~flocculant/xubuntu-docs/xubuntu-docs/+merge/274703
[21:08] <flocculant> none of which I actually did :D
[21:10] <flocculant> Diff against target: 	182719 lines (+33977/-27848) (has conflicts)
[21:10] <Unit193> :D
[21:11] <flocculant> I give up - losing interest with this rapidly :p
[21:11] <knome> rrright...
[21:11] <knome> i'll figure it out
[21:11] <knome> just don't touch it again
[21:11] <knome> :P
[21:12] <flocculant> knome: all that I have done is bzr branch lp:xubuntu-docs, changed the dozen or so files I changed before, commited it, tried to push it - and it threw a fit then --overwrite appeared to push it ok
[21:12] <knome> yeah
[21:12] <flocculant> no wonder people start to get involved and then give up
[21:13] <knome> the reason why you see the huge diff is that you have now merged main into your branch
[21:13] <knome> (main did have a lot of changes)
[21:13] <flocculant> right
[21:13] <knome> so you are seeing both your changes, and mine
[21:14] <flocculant> should have just deleted my branch and started again
[21:14] <knome> which i guess i could have committed slightly more cleanly
[21:14] <knome> (but only slightly)
[21:14] <knome> i'll take a spot on the dining table and figure it out
[21:16] <flocculant> mmm
[21:16] <flocculant> so if you did stuff with the .ent file(s) and I had added something to one here I guess that's all gone now
[21:17] <knome> i'll make sure it gets all in.
[21:17] <knome> don't worry
[21:17] <flocculant> anyway - I'm off, I only turned the machine to check a few things, saw slickymaster's comments fixed those and commented where I didn't
[21:18] <flocculant> then it all went wrong ...
[21:18] <knome> np
[21:18] <flocculant> cya tomorrow :)
[21:18] <knome> hf
[21:18] <flocculant> sleep I want - 3 nights of 3 or 4 am's
[21:18] <flocculant> :D
[21:18] <knome> huh
[21:18] <knome> good nighty then ;)
[21:18] <SwissBot> feed xubuntu-docs had 13 updates, showing the latest 3
[21:30] <knome> flocculant, ok done; see https://code.launchpad.net/~flocculant/xubuntu-docs/xubuntu-docs/+merge/276351 for the "actual" diff against the xenial branch
[21:45] <knome> wut?
[21:49] <knome> what was my quit message?
[21:50] <knome> because i think i just chrashed irssi...
[21:55] <krytarik> knome: "* knome has quit (Remote host closed the connection)"
[21:55]  * knome facepalms
[21:55] <knome> totally inaccurate
[21:56] <knome> i typed a /command and BOOM
[21:57] <krytarik> knome: Also, please refer to  http://paste.openstack.org/show/YAxHwIMt52LGwcrFVmoP/  reg. the changes to 'desktop-guide/libs/xubuntu.ent' previously made by flocculant.
[21:58] <knome> hmm
[21:58] <knome> i wonder why launchpad totally forgot about that
[21:58] <knome> i tried to find the previous commit by him, but no
[21:59] <knome> maybe it was the --overwrite...
[21:59] <krytarik> Yep.
[21:59] <krytarik> Like he said, that killed it.
[21:59] <knome> mhm
[21:59] <knome> stupid.
[22:00] <knome> ok, pushed
[22:00] <knome> well, pushing
[22:00] <knome> done
[22:19] <knome> krytarik, so... as i said before
[22:19] <knome> there is some work with the docs scripts
[22:19] <knome> i can help with that too
[22:19] <knome> one thing we should probably reconsider is the structure on how the docs are built
[22:19] <knome> now the startpage is on the root directory, language directories for docs directly below it
[22:20] <knome> if we get new contributor docs, wouldn't it make sense to put each of them under their own subdir
[22:21] <knome> that would help with some of the linking stuff too
[22:27] <krytarik> knome: Yeah, I guess that'd be a workable solution.
[22:31] <krytarik> knome: Btw, these are the other ones :P -
[22:31] <krytarik> - Release notes on website and wiki: "LibreOffice Calc and Writer and [→are] now included."
[22:31] <krytarik> - http://xubuntu.org/news/building-xubuntu-documentation-package-locally/:
[22:31] <krytarik>   'fonts-droid' added in Wily too, but installed in Xubuntu by default
[22:31] <krytarik> - http://xubuntu.org/help/: "Wily Werewolf 15.10" is split in two links
[22:33] <knome> heh
[22:33] <knome> this is why you shouldn't let others update the website ;)
[22:34] <krytarik> :D
[22:36] <knome> say
[22:37] <knome> should the scripts always require a template
[22:37] <knome> or should we fall back to desktop-guide?
[22:38] <krytarik> For clarity, I guess I'd prefer specifying it.
[22:38] <knome> yep


[11:16] <pwaller> Hi Folks, I just hit this kernel bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
[11:17] <pwaller> The advise of the BTRFS developers is to update to 3.15 or above
[11:17] <pwaller> s/advise/advice/
[11:17] <pwaller> I tried adding https://launchpad.net/~kernel-ppa/ppa and/or https://launchpad.net/~kernel-ppa/pre-proposed to my trusty system, but both resulted in 404 when doing `apt-get update`
[11:18] <pwaller> What is a good way to get a more recent kernel on 14.04?
[11:29] <apw> pwaller, that isn't exactly the most helpful advice
[11:29] <pwaller> apw: ah. Any better suggestions?
[11:30] <apw> well they could suggest a fix instead of a blanket upgrade to a newer kernel
[11:30] <apw> when utopic releases tehre will be a 3.16 kernel available in 14.04 but that is not yet ready for production use, nor available in 14.04
[11:30] <pwaller> hm, OK.
[11:31] <pwaller> apw: It was advice from a random on IRC, and I suppose they were trying to help me hit the ground running again.
[11:31] <pwaller> apw: can you think of any ways I can help the bug along or is it best to sit on my hands for now?
[11:31] <apw> pwaller, are you seeing any ill effects or only these warnings
[11:31] <pwaller> apw: I've determined that these are warnings
[11:31] <pwaller> apw: they all appear to be relating to caches which can be discarded
[11:32] <pwaller> (according to notes found on mailing lists and the advice from #btrfs)
[11:32] <apw> yeah that appears to match my understanding, i don't expect any of these to stop things working
[11:32] <apw> the soft lockups all clear before 46s or whatever the second check is
[11:32] <pwaller> apw: a cursory check suggests things are working
[11:32] <pwaller> apw: I can't parse your last statement
[11:33] <pwaller> apw: the soft lockups are happening after >48h running
[11:33] <apw> the softlockup warnings all say 22/23s which indicates they did not continue to be locked up, they resolved each individual lockup
[11:33] <pwaller> ah! I misread that.
[11:33] <apw> those are serious when they say like 23s, 46s, 90s, 200s, ...
[11:33] <pwaller> gotcha.
[11:34] <pwaller> Except that it is preventing the machine from being useful
[11:34] <pwaller> but I get what you mean.
[11:34] <apw> ok so there are ill effects, whci are ?
[11:34] <pwaller> apw: http and ssh stop responding
[11:35] <pwaller> apw: my interim "fix" was going to be to configure a watchdog which rebooted the system, but maybe that wouldn't work
[11:35] <xnox> depends on the workload and how full the fs is. Do you rebalance regularly?
[11:35] <pwaller> apw: I guess the BTRFS FS wasn't accepting writes.
[11:35] <pwaller> xnox: stupid question from me: do I need to rebalance if it just on one block device?
[11:35] <pwaller> xnox: FS is 87% full
[11:35] <apw> hmmm, i don't think those warnings are necessarily even related.  but anyhow, you should cirtainly file a bug against linux if its getting hung up
[11:36] <apw> and we can suggest some debug kernels to try etc and see if we can figure out if it is fixed in later versions
[11:36] <pwaller> apw: on the kernel tracker?
[11:36] <apw> on launchpad, run "ubuntu-bug linux"
[11:36] <pwaller> apw: the link above is on launchpad
[11:36] <pwaller> Oops, no it isn't!
[11:37] <pwaller> Oh, yes - the link I sent is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
[11:37] <pwaller> apw: so I did already file one there
[11:39] <apw> ok as btrfs upstream are suggesting v3.15 I would first suggest you test with a v3.15 mainline kernel;
[11:39] <apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
[11:40] <apw> though these are manual installs and do not upgrade automatically; so they are only useful for testing
[11:40] <pwaller> ah, I missed the /mainline of ~kernel-ppa
[11:40] <apw> if that works try v3.14, if it does not try v3.16-rc7
[11:40] <apw> and report that back to the bug, if that shows it is fixed somewhere already we can start a bisect for the fix
[11:41] <pwaller> apw: it's a bit difficult to bisect if it isn't triggerable, isn't it?
[11:41] <apw> very much so, sadly
[11:41] <apw> but if we have a bracket, we could at least look at the btrfs changes and see if anything "sticks out"
[11:42] <pwaller> okay
[11:43] <pwaller> apw: we reached more than 12 days uptime before the last problem I think
[11:43] <pwaller> so it is going to be difficult to observe
[11:46] <pwaller> apw: woah. Just looked in the nginx log
[11:46] <pwaller> apw: which is not on the BTRFS drive - it's full of null characters at the point of the fault
[11:47] <pwaller> There are ~2280 null characters
[11:48] <pwaller> apw: and indeed there were no HTTP requests serviced for the duration of the fault (whilst the kernel was reporting 20s soft lockups)
[11:49] <pwaller> afk for lunch, back in <1h.
[12:37] <pwaller> back
[13:16] <pwaller> Does anyone how I can run apport-collect but check that the output doesn't contain company secrets?
[13:49] <pwaller> Does anyone know where /dev/watchdog comes from? My reading is that it should be there by standard, but I can't find it
[13:51] <pwaller> Ah, have to load softdog
[14:02] <bjf> smb, did you see that bug 727459 seems to have come back for a user?
[14:03] <smb> bjf, I saw some updates to the bug but have not gotten to that, yet
[14:27] <smb> bjf, I am very doubtful this is just the same bug, so I asked to open a new report
[14:57] <bjf> smb, ack
[14:59] <jsalisbury> **
[15:00] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:00] <jsalisbury> **
[15:20] <Joe_CoT> bjf, unless I'm missing something, think your automated script might be faulty https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349883 It asked me to run apport to collect logs because logs were missing, but the logs apport attached were the same as ubuntu-bug attached in the first place. Is there some log that apport didn't pick up it should've?
[15:23] <pwaller> How do I specify that a kernel module should be loaded? Is it via /etc/modules? Is there a /etc/modules.d equivalent or do I have to edit that one file?
[15:23] <smb> Joe_CoT, Maybe the bot acts too quickly. Seems like status changed by apport right after
[15:23] <pwaller> (I want to make a salt state which causes a module to be updated on boot so I don't particularly want to mess with /etc/modules)
[15:23] <smb> Its now confirmed so it should be ok.
[16:36] <Joe_CoT> smb, I think the issue is probably that ubuntu-bug collects the same logs, but doesn't set the tag apport-collected, which the bot cues off of
[16:37] <smb> Joe_CoT, That tag seemed to be there by the time I looked.
[16:39] <Joe_CoT> 10:53 I put the bug in with ubuntu-bug, which had all the logs attached. 11:00 the bot replied, saying the logs were missing, and to run apport-collect. 11:10 I ran apport-collect, which attached the same logs, but added the tag apport-collected
[16:40] <Joe_CoT> apport-bug was already there, apport-collected was not
[16:46] <smb> Hm, ok. bjf, so I am not sure why this happened ^.
[16:46] <smb> Joe_CoT, Anyway I am looking into it
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[17:12] <_`_> wait that was it, jsalisbury ?
[17:24] <ppisati> rtg: git://kernel.ubuntu.com/ppisati/ubuntu-embedded.git
[17:24] <ppisati> rtg: i'm still working on it, so it's pretty rought right now
[17:24] <ppisati> rtg: but it works
[17:24] <ppisati> rtg: for your mirabox board run as:
[17:25] <ppisati> rtg: sudo ./make_img.sh -b mirabox -d 14.10
[17:26] <ppisati> rtg: dd the .img file that it creates to an sd, pop in in your mirabox and follow the instruction in "mirabox-uboot-env.txt"
[18:03] <rtg> ppisati, I'll give it a run
[18:05] <hallyn> 3.13 most certainly did not resolve the btrfs sync performance issues :)
[18:05] <hallyn> uh, :(
[21:34] <cantstanya> lol
[21:56] <dannf> kamal: i'm seeing a build regression w/ trusty master-next that i've bisected to a <IP_ADDRESS> patch
[21:56] <dannf> kamal: is there a 3.13.11.y git tree i could use to demonstrate whether or not it is a problem outside of ubuntu?
[23:16] <kamal> dannf, http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
[23:17] <kamal> dannf, what's the problem patch?
[23:17] <dannf> kamal: a ptrace patch - see my e-mail to kernel-team@
[23:18] <dannf> kamal: not at all an obvious problem (at least to me), i haven't debugged it yet
[23:18] <dannf> macro fun no doubt
[23:23] <kamal> dannf, yeah, its not clear why that patch would cause that build failure
[23:27] <kamal> dannf, so yeah, if you can (or can't) reproduce the failure with that 3.13.y stable repo, that would be interesting to know
[23:29] <kamal> dannf, and/or I can try to reproduce it -- what config are you using? -- fwiw, I didn't see any build failure with the few ARM configs I test (tegra, omap2plus, imx_v6_v7).
[23:31] <dannf> yeah, weird, can't reproduce with pristine
[23:32] <dannf> but bisecting definitely led to that one, then going back to top of trusty master-next and reverting continued to show that it was the breaker


[23:10] <AutoMatrix> Good evening
[23:11] <AutoMatrix> where do I go to get help for a VP380 camera ?


[01:00] <Knightlust> hmmm, someone should ban raeon
[01:02] <Knightlust> !whowas raeon
[01:02] <butiki> Knightlust: Error: "whowas" is not a valid command.
[01:03] <Knightlust> cripes, logging was suppressed on my irssi, should've captured that guys' ip addy
[01:20] <epal> 11:14  --> raeon<EMAIL_ADDRESS>has joined #ubuntu-ph :D
[01:28] <Knightlust> thanks epal
[01:28] <Knightlust> also reconfiguring my irssi
[02:10] <Terminus> Knightlust: someone should ban daw. ikaw naman pala yung may op eh. =D
[02:11] <Jucato> sino kelangan i-ban?
[02:11] <Knightlust> Jucato: nvm na lang
[02:11] <Jucato> oo na sige na. wala ako dito
[02:11] <Knightlust> dyn ip add nya, he'll just reboot his router
[02:11] <Jucato> pffft
[02:11] <Knightlust> hehehe
[02:11] <Knightlust> thanks!
[02:11] <Jucato> nick+ip ban
[02:12] <Jucato> wala akong kapaguran mag ban. tamad lang ako maglinis
 11:14  --> raeon<EMAIL_ADDRESS>has joined #ubuntu-ph :D
[02:15] <Jucato> ayan
[02:15] <Knightlust> hehe, thanks much!
[02:15] <Jucato> ping me if something comes up.  XD
[03:02] <Terminus> or more like, cause the engineering dept head to switch to headless chicken mode. =D
[03:05] <Jucato> lol
[03:07] <Jucato> having to ban someone isn't the issue. the issue is that we lack people who can ban. wala kaming powers ni zak mag dagdag permanently ng OP
[03:07] <Jucato> kahit si dous hind rin kaya
[03:07] <Jucato> not even ealden!
[03:07] <Jucato> isang tao lang may kaya nun
[03:07] <Jucato> hulaan nyo na lang sino :)
[03:09] <Terminus> Jucato: ikaw? =D
[03:09] <Terminus> it's either you or Knightlust. hehe
[03:09] <Jucato> wala nga eh
[03:09] <Jucato> this is the best I can do :(
[03:09] <dous> jsg?
[03:10] <Jucato> bingo
[03:10] <Jucato> heh
[03:10] <Terminus> ah... hehe
[03:10] <Terminus> palagi nasa G+. XD
[03:13] <Jucato> hehehe
[03:13] <Jucato> oh well
[03:31] <Knightlust> yeah, butiki may be the right candidate... we should ping jm for the added functionality, and ping jsg to op butiki
[03:32] <epal> eggdrop mga sir si butiki? :D
[03:34] <Jucato> lol
[03:34] <Jucato> if jsg can op butiki, he can also op you. that's the problem for now :)
[04:30] <Jucato> Meh.pldt -_-
[04:53] <VerdeNube> :)
[04:55] <Knightlust> epal: butiki's a supybot iirc
[05:01] <Knightlust> brb, updated my kernel. my server needs a reboot
[07:57] <VerdeNube>
[12:37]  * Craw^ mano kay shipcode
[12:46] <shipcode> craw
[12:46] <shipcode> nsa #rootcon din kami
[16:44] <arscariosus> im now using ubuntu 11.10beta2
[16:46] <shipcode> nice
[16:46] <shipcode> arscariosus
[16:46] <shipcode> may rotcon channel din
[16:46] <shipcode> #rootcon
[16:46] <shipcode> guys punta din kau dun
[16:47] <arscariosus> oks sige add ko na hehe
[16:48] <Craw^> epal: let's join us @ #rootcon lol
[16:49] <arscariosus> i'll promote it to our school's LUG
[16:49] <shipcode> hehe
[16:49] <arscariosus> :D
[19:25]  * arscariosus is going to sleep now