[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 <phillip@ubuntu.com>
[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 ?