=== philwyett [n=philip@bb-87-81-146-45.ukonline.co.uk] has joined #ubuntu-kernel === johanbr [n=j@blk-224-156-151.eastlink.ca] has joined #ubuntu-kernel === kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu] has joined #ubuntu-kernel === marcin_ant [n=marcin@194.114.146.126] has joined #ubuntu-kernel === ivoks [n=ivoks@19-55.dsl.iskon.hr] has joined #ubuntu-kernel === philwyett [n=philip@bb-87-81-146-45.ukonline.co.uk] has joined #ubuntu-kernel === jml_ [n=jml@59.167.203.115] has joined #ubuntu-kernel === madc [n=d@71-81-56-119.dhcp.slid.la.charter.com] has joined #ubuntu-kernel === macd [n=d@adsl-156-75-197.msy.bellsouth.net] has joined #ubuntu-kernel === philwyett [n=philip@bb-87-81-146-45.ukonline.co.uk] has joined #ubuntu-kernel === lazka [n=lazka@85-124-41-166.dynamic.xdsl-line.inode.at] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === johanbr [n=j@blk-224-156-151.eastlink.ca] has joined #ubuntu-kernel === rpereira [n=rpereira@ubuntu/member/rpereira] has joined #ubuntu-kernel [02:56] 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] which kernel is this? [02:56] I updated 2 hours ago. [02:57] so, -15.27? Can you verify? [02:57] I know is 2.6.20-15 [02:57] How can I verify if it isn't booting at all? [02:58] boot from a desktop cd, chroot, dpkg -l linux-image-2.6.20-15-generic [02:59] OK. [02:59] I will do it. [02:59] Which version is working? [03:00] -15.27 WFM, but I don't have affected hardware [03:00] OK. [03:00] I will keep my notebook kernel for security reasons..... [03:03] I'm burning the CD, so wait some minutes please. [03:13] crimsum: 2.6.20-15.27 [03:13] crimsun: 2.6.20-15.27 [03:16] crimsun: kernel 2.6.20-15.25 works with this computer. [03:16] which mass storage controller(s) do you have? [03:16] If I install on chroot, will I have a problem? [03:17] at this point, the regression from -15.25 is what's interesting. [03:18] OK. Mu mass storage controller is: product: 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE [03:18] Driver: driver=ata_piix [03:19] Do you need another info? [03:20] lspci -vvn [03:20] should be identical to mine [03:20] dmesg is what we need [03:23] kylem: how do I get dmesg with the defectuous kernel? [03:25] photograph it or something? [03:26] But when I use the defectuous kernel, my computer get stucked on grub with message: "Error 17: Cannot mount selected partition" [03:26] I've resorted to writing dmesg in the past. Not fun, but certainly feasible. === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [03:30] I think that I found the error.... [03:31] At least my computer error. [03:31] When I'm installing a kernel with my CD using chroot and dpkg -i linux-image.... I got the error: [03:32] findfs: Unable to resolve 'UUID=XXXXXXXXXXX...XXXXXX' [03:33] Cannot determine root device. Assuming /dev/hda1 [03:33] This error is probably caused by an invalid /etc/fstab [03:33] That was the error... Sorry for so much pasting... [03:34] My sda1 is my /home [03:36] The UUID printed is correct, but my / partition is hda3. [03:36] So my /etc/fstab is corrected. [03:40] 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] s/hava/have [03:42] Summarizing: The problem is with the auto generation of grub menu.lst file. [03:43] rpereira, why use UUID in the first place ? [03:43] rpereira, just delete the UUID [03:45] is there donkey kong available for ubuntu. :P [03:45] I do not use it. Some time on updating Ubuntu change from /dev/sdaX to UUID... [03:45] ok ok. [03:45] :) [03:46] 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] crimsun: did you got my messages? [03:47] rpereira: sorry, was away. Yes, I just read scrollback. [03:47] so the kernel is fine, which is a relief, but the upgrade somehow broke? [03:47] Yeap. [03:48] Maybe it is the post-instalation script or grub (if it was upgraded). [03:49] 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] lamont, a p2? -generic [03:53] kylem: yeah - iz glorified printer server [03:53] state of the art about the time you were born... :-) [03:53] oops. ECHAN === kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu] has left #ubuntu-kernel [] === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === FOAD [n=dok@dinah.blub.net] has joined #ubuntu-kernel === rajlinux [n=raj@122.164.13.63] has joined #ubuntu-kernel [06:33] 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] please see LWN.net archives. [06:39] I cant find there [06:39] is there any other place to search? [06:40] 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.. === m0rg0th [n=manugarg@220.225.228.97] has joined #ubuntu-kernel === bdgraue [n=bdgraue@dynadsl-080-228-85-023.ewetel.net] has joined #ubuntu-kernel === defendguin [n=supertux@cpe-72-181-7-135.houston.res.rr.com] has joined #ubuntu-kernel === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-kernel === macd [n=d@adsl-156-75-197.msy.bellsouth.net] has joined #ubuntu-kernel === macd [n=d@adsl-156-75-197.msy.bellsouth.net] has joined #ubuntu-kernel === macd [n=d@adsl-156-75-197.msy.bellsouth.net] has joined #ubuntu-kernel === drago [n=drago@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-kernel [08:35] Hi, does anyone working on bug abt /proc/kcore ? [08:39] Nafallo: being unable to sync with Debian is unfortunate, but not a totally overriding concern [08:39] and if we ask nicely it's possible that Debian might add the epoch too [08:42] morning, Colin === lamont [i=lamont@nat/hp/x-cc3bc171ccc123d5] has joined #ubuntu-kernel === jan__ [n=jan@proxy-6.kliksafe.nl] has joined #ubuntu-kernel === Lure [n=lure@external-7.hermes.si] has joined #ubuntu-kernel === infinity [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-c7d108e7f9b7a12d] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-0ee76ba41a9ab98b] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-5f2ba173ca77f099] has joined #ubuntu-kernel === jan [n=jan@proxy-6.kliksafe.nl] has joined #ubuntu-kernel === cassidy [n=cassidy@host-213-189-171-21.brutele.be] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-93eaede51b1168ea] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-4fb06ad7ad5c9649] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-7a4ebaa734d9dccd] has joined #ubuntu-kernel === abogani [n=abogani@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-a682af64a6095cc3] has joined #ubuntu-kernel === Keybuk [n=scott@yttrium.canonical.com] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-a2517de5261f6a17] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-930f699c7d288154] has joined #ubuntu-kernel === gortiz [n=gortiz@88.87.105.4] has joined #ubuntu-kernel === tijsco [n=matthijs@cc237736-a.groni1.gr.home.nl] has joined #ubuntu-kernel === lamont [i=lamont@nat/hp/x-0facbf1072764f4d] has joined #ubuntu-kernel === TheMuso_ [n=luke@dsl-220-235-192-49.nsw.westnet.com.au] has joined #ubuntu-kernel === jan [n=jan@proxy-6.kliksafe.nl] has left #ubuntu-kernel ["Leaving"] === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === ivoks [n=ivoks@wall2.grad.hr] has joined #ubuntu-kernel === rikai_ [n=rikai@unaffiliated/rikai] has joined #ubuntu-kernel === heno [n=henrik@ubuntu/member/heno] has joined #ubuntu-kernel === mdz_ [n=mdz@yttrium.canonical.com] has joined #ubuntu-kernel [11:07] 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] bug 106864 [11:10] ubotu isn't in here === Eruantalon [n=hans@5634185c.rev.stofanet.dk] has joined #ubuntu-kernel [11:26] heno: too little information to be able to diagnose; I've posted a message requesting more information === bdgraue [n=bdgraue@dynadsl-080-228-85-023.ewetel.net] has joined #ubuntu-kernel [11:27] cjwatson: ok, thanks. almost seems like a bad disk, but ideally the kernel should cope, no? [11:27] I see no reason to infer a bad disk from that === Eruantalon [n=hans@5634185c.rev.stofanet.dk] has joined #ubuntu-kernel === pkl_ [n=phillip@lougher.demon.co.uk] has joined #ubuntu-kernel === MrNOKIA1 [n=user@86.121.182.108] has joined #ubuntu-kernel === rikai_ is now known as rikai === MrNOKIA [n=user@unaffiliated/mrnokia] has joined #ubuntu-kernel === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel === abogani [n=abogani@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === statik [n=emurphy@canonical/launchpad/statik] has joined #ubuntu-kernel === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel === pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl] has joined #ubuntu-kernel === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === rtg_ [n=rtg@gn-216-166-171-58.mtwireless.net] has joined #ubuntu-kernel [02:30] g'day === pkl_ [n=phillip@lougher.demon.co.uk] has joined #ubuntu-kernel === ivoks [n=ivoks@34-23.dsl.iskon.hr] has joined #ubuntu-kernel [02:34] hi zul === marcin_ant [n=marcin@194.114.146.126] has joined #ubuntu-kernel [02:46] kylem: this VMWare performance issue has now been confirmed by Keybuk [02:46] kylem: I'm guessing it's something to do with the PIIX driver changes [02:46] hmm, bug #? [02:47] i'll take a look [02:49] kylem: hadn't reported it yet since I thought it was a problem with this PC [02:49] kylem: installing current dailies in vmware with ubiquity takes much, much longer than it did before [02:49] any idea which day it changed? :\ [02:49] (approximately) [02:50] kylem: yes, I mentioned it in this channel [02:50] let me find the log [02:51] kylem: first noticed 12 April ~16:56 BST [02:51] ok, thanks. [02:52] could i get a dmesg from one of the booted vmware instances? [02:52] kylem: yep [02:53] awesome. === tijsco [n=matthijs@cc237736-a.groni1.gr.home.nl] has joined #ubuntu-kernel [02:57] kylem: http://people.ubuntu.com/~mdz/temp/dmesg [02:57] thanks. [02:58] default vmware config for Ubuntu (SCSI disk, ATAPI CD-ROM) === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [02:59] mdz: http://people.ubuntu.com/~scott/dmesg.vmware-live [02:59] (booting the Live CD) [02:59] Keybuk: 403 [03:00] fixed [03:01] Keybuk: is not [03:01] err [03:02] fixed harder === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel [03:03] pkl_: can you help kyle with this? kyle has been doing pretty long hours lately. :) [03:04] Ok [03:04] Keybuk: fixed for me (403 err) [03:05] 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] pretty sure vmware was using ata_piix before [03:05] kylem: no, I don't [03:06] let me grab a beta CD and compare [03:06] Keybuk, thanks. [03:07] downloading... [03:07] i don't see how this could drop the performance though, this driver is what would have been using for years pevious [03:07] I have a beta install in vmware already [03:07] kylem: maybe the new driver made things much faster? [03:08] hrm. [03:08] I can see the difference just booting the live CD [03:08] comes up much quicker [03:08] kylem: do you not have vmware locally? [03:09] kylem: yes, beta used scd0 and ata_piix [03:10] kylem: is it possible to force ata_piix in current feisty to test? [03:10] how come we reverted from libata to ide for that driver? [03:10] Keybuk: because the new one was fucked [03:11] no, we reverted for pata_amd... [03:11] keybuk: bug 96857 [03:11] Pre-moving over to libata (-12 kernel), the cdrom driver would resumably have been this driver? [03:11] s/resumably/presumably/ [03:12] mdz, oh. [03:12] so we broke vmware to fix qemu? [03:13] as kyle says, vmware probably used to use piix [03:13] can somebody boot dapper and/or edgy to test? my vmware box is doing other things at the moment [03:14] Keybuk: weren't you seeing ATA errors in vmware too? [03:14] that was one of the rationales for reverting IIRC [03:15] cjwatson: I was seeing lots of messages, yeah -- but it did at least work [03:15] if it worked, why was it being brought up as an issue near release time? [03:15] keybuk: it works now, but slowly? [03:16] I brought it up quite a long time before release time :) === johanbr [n=j@blk-224-156-151.eastlink.ca] has joined #ubuntu-kernel [03:17] 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] in the case of vmware, we're using a virtual scsi disk for hard disk [03:18] argh, Stanislaw and Dmitry hijacked that bug with an unrelated issue. [03:19] pkl_: we're using SCSI hard disks, which is the default [03:19] pkl_: vmware gives you the option of selecting SCSI (BusLogic or LSILogic) or IDE [03:20] http://people.ubuntu.com/~scott/dmesg.vmware-beta [03:20] cjwatson: the error messages were sufficiently scary that it didn't seem wise to ignore, even if it appeared to work [03:21] I don't see the errors with beta, and performance is good there [03:21] 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] pkl_: that's my assumption, yes [03:22] - 96857: Broken PIIX support, mostly showed under emulation. This [03:22] affected qemu, kvm and vmware. All of which have an emulated PIIX [03:22] IDE chipset. The disk would work fine, but CDROM support would [03:22] not. Resolved by reverting back to piix.ko (IDE) for Intel PIIX [03:22] pata chipsets. Piix.ko is much more tested and stable. [03:22] if all we did was switch to the same driver we were using before, I have no explanation for the performance regression [03:22] as a reminder, that was Ben's rationale [03:22] cjwatson: yes, Ben said he had reports of it actually not working [03:22] Could the slow down be completely unrelated? [03:22] though we weren't able to reproduce them in our setups [03:22] he also explained by phone that it affected some older hardware [03:22] pkl_: there is always that possibility, yes [03:22] pkl_: SCSI doesn't need to go through libata ;) [03:22] pkl_: do you know of any other changes which may have caused it? [03:23] beta was using ata_piix, today is using piix [03:23] pkl_: did we pull a libata update post-beta? [03:24] Keybuk: yeah, just pondering that [03:24] so beta had neither performance problems nor errors with ata_piix [03:24] 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] yet we reverted to piix to fix the errors? [03:24] mdz: confirmed [03:24] cjwatson: regressed since *beta*, not edgy or dapper! [03:24] Keybuk: beta used ata_piix, it may have had this piix problem [03:24] beta was using ata_piix so the piix module's behaviour is not known [03:24] 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] libata update went in post-beta [03:24] ah, good point [03:24] sorry [03:25] pkl_: this problem began around 12 april [03:25] pkl_: squashfs update didn't make final [03:25] brain was unsuccessfully on two tracks there [03:25] it's in git head but not in the branch that actually landed for release [03:25] errors in ata_piix was regression between feisty beta and today [03:25] cjatson: there was an update from Squashfs 3.1 to 3.2-r2 that did go in... [03:25] speed of piix is regression between dapper/edgy and unknown before today [03:25] this keyboard is playing up... missing characters. [03:25] oh, right, I thought you meant squashfs setpageerror [03:26] fair point, that could be implicated [03:28] can we get lspci -vvnn from vmware, qemu, kvm, parallels? [03:28] 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] http://people.ubuntu.com/~mdz/temp/lspci-vmware [03:31] cjwatson: ^^ [03:31] 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] ok, that's PCI_DEVICE_ID_INTEL_82371AB === cjwatson grabs the qemu source to xref [03:35] when did the reversion happen, btw? [03:35] -15.23 [03:36] my laptop is running 15.27 and has ata_piix loaded, not piix === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [03:36] BenC: good morning [03:36] mdz: hey [03:37] rough weather here last night...power went out like 6 times [03:37] Keybuk: yes it's only for a few pci ids [03:37] mdz, can you past the next line? (the subvendor line) [03:37] five, I think === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel [03:37] kylem: URL above [03:37] parallels (MBP) 00:1f.1 IDE interface [0101] Intel Corporation 82801BA IDE U100 [8086:244b] [03:37] sorry, missed that, thanks mdz [03:38] did I wake up in the middle of a kernel crisis? [03:38] ok, we want to match on subvendor/subdevice if this is something we want to fix. [03:38] qemu is 8086 7010 I think [03:38] which is PCI_DEVICE_ID_INTEL_82371SB_1 [03:39] subsystem: Intel corporation unknown device [8086:4541] [03:39] so qemu and vmware at least are using different piix drivers, which offers an obvious possibility [03:39] BenC: at least a potential crisis [03:39] BenC: serious cdrom performance regression in vmware apparently since the ata_piix to piix reversion [03:39] 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] I'm wondering if we blatted back more than we needed to [03:39] BenC: Keybuk reproduced it in his vmware as well [03:40] how about we just roll a test image with that single re-re-re-reverted? [03:40] I don't like just reverting this because it fixed several potential problems [03:40] the bad thing about ata_piix was the exceptions on the cdrom [03:40] has anyone checked qemu lately? [03:41] or kvm, with current images? [03:41] cjwatson: I had several people confirm qemu working [03:41] I can test kvm real quick [03:41] BenC: we discovered that those appeared sometime after beta [03:41] BenC: beta works with ata_piix just fine without errors and with good performance [03:41] mdz: right, they happened after the drivers/ata/ sync with libata-dev stable [03:41] the libata updates weren't done for fun though - they fixed other problems, right? === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel [03:41] right [03:42] mainly they enabled DMA for pata [03:42] which I believe is the source of the exceptions on ata_piix for ATAPI devices [03:43] mdz: check if dma is enabled on your emulated cd drive? [03:43] but disabling DMA for ATAPI in ata_piix would probably get us the same problem that you are experiencing now [03:43] Mithrandir: it is, in both cases [03:43] checked that [03:43] note, we've got near zero changes to drivers/ide/ compared to stock 2.6.20 [03:43] only thing of note is ide-acpi [03:44] 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] you can disable that with a module param, I can find it if you want to test it [03:44] BenC: when did we switch from piix to ata_piix? [03:44] mdz: for some PCI id's we've been using it since dapper, I believe [03:45] 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] BenC: 8086:7111 is the ID in question [03:45] so it's been a gradual change [03:45] that one would be one of the last to change [03:46] that's why it was part of the 5 moved back to piix during our Great Kernel Fixing Extravaganza [03:47] let me copy a feisty image over and test kvm real quick [03:48] also need to disconnect my generator so I can switch power back to the barn for possible builds === poningru [n=poningru@adsl-074-245-140-197.sip.gnv.bellsouth.net] has joined #ubuntu-kernel [03:49] quick question [03:49] why does the kernel get symlinked to /? [03:49] and the init image as well [03:49] historical [03:50] any particular historical reason? [03:50] like sysv spec or something? [03:50] 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] ah hmm [03:50] does deb also follow this? [03:50] yes, we inherited it from Debian [03:50] cool thanks mate :) [03:51] specifically arm, hppa, powerpc, s390, and sparc put it in /boot instead [03:52] it also depends somewhat on the boot loader [03:52] hmm I know grub can load from any place [03:52] oh right ppc have their own dont they [03:52] ok I see what you are saying [03:53] there are lots and lots of complications particularly when a separate /boot is involved [03:53] so moving the symlink must be done carefully [03:53] poningru: also /etc/kernel-img.conf is what tells it to do so [03:53] right, set up by base-installer (d-i) or the live filesystem build script (ubiquity) [03:54] hmm ic [03:54] assuming kpkg will do this for you automagically? [03:54] herd-1 took 1:32.6 [03:55] BenC: you have a local vmware, right? [03:57] ws6 [03:57] I'll try it and kvm [03:58] herd-2 took 1:59.3 [04:00] herd-3 took 1:22.1 [04:03] herd-4 took 1:29.2 [04:05] cool, I have -15.27 images rsync'd already [04:05] BenC: do you see the same problem with ws6, or no? [04:05] getting ready to test [04:05] had to copy it to the laptop [04:05] herd-5 took 1:28.7 [04:07] (all of those were using piix) [04:08] and current is ? [04:08] hmm, so it switched between herd-5 and beta [04:08] Mithrandir: current is booting ;) [04:08] ok === cassidy [n=cassidy@host-213-189-171-21.brutele.be] has joined #ubuntu-kernel [04:09] mdz: we switched to ata_piix between herd-5 and beta, afaict [04:09] and switched back between beta and today [04:09] Keybuk: that's what I just said [04:09] BenC: so what changed in piix since beta, if anything? [04:09] mdz: nothing [04:10] weird [04:10] what kernel rev did Herd5 use? [04:11] 2.6.20 stable, from what I remember [04:12] wait, I might be wrong about piix changes from upstream... [04:12] current is 3:02.7 [04:12] piix clearly changed between herd-5 and current [04:13] something affecting it did, at least [04:13] nope, there isn't [04:13] piix is exactly the same as 2.6.20 except out PCI id allocation [04:14] s/out/our [04:16] beta (with ata_piix) booted in 1:59.5 [04:17] interesting, so still slower [04:17] ata_piix was slower than the old piix, and new piix is slower than that === BenC_ [n=bcollins@collinsap1.phunnypharm.org] has joined #ubuntu-kernel [04:18] that was ugly [04:18] ws6 locked me up solid [04:18] me> the host? [04:18] yeah [04:18] no caps lock, no ping, nothing [04:19] let's give qemu a try [04:19] beta booting with piix [04:19] BenC: what about ide-cd? anything different there? [04:20] -#define VERBOSE_IDE_CD_ERRORS 1 [04:20] +#define VERBOSE_IDE_CD_ERRORS 0 [04:20] that's our only diff between upstream [04:21] and that patch has been in since dapper [04:21] or even breezy === gnomefre1k [n=gnomefre@adsl-144-154-3.rmo.bellsouth.net] has joined #ubuntu-kernel [04:21] beta (with piix) booted in 1:57.1 [04:21] Keybuk: what kernel is in herd 5 and beta? [04:22] beta with piix is notably quite perky [04:22] ah, so piix isn't broken in beta? [04:22] icons appearing instantly [04:22] etc. [04:22] what kernel is in beta? [04:22] cat /proc/version_signature [04:22] (I'd put down the slightly slower boot to lack of readahead update before it, since hal/gdm were reordered) [04:22] 1.5x isn't "bad" ... 3m is bad [04:22] 2.6.20-12-generid [04:23] BenC: Ubuntu 2.6.20-12.20-generic [04:23] Keybuk: did you try current with ata_piix? [04:23] ok, thanks [04:23] BenC: would a new_id force current with ata_piix ok? [04:23] Keybuk: yes [04:24] it should just modprobe though, right? [04:24] BenC: how can I generate a diff from 2.6.20-14.22 to current using git? [04:24] (ie. claim if I just load the driver, without needing to force) [04:24] 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] mdz: git-diff-tree -p Ubuntu-2.6.20-14.22..HEAD [paths] > foo.diff [04:25] if you exclude a path, you'll get everything [04:25] mdz: drivers/ide has changed since before beta [04:25] except for the PCI id's [04:25] has changed => has not changed? [04:25] has not [04:25] correct [04:26] BenC: err, doesn't seem to be forcing it [04:26] Keybuk: did piix load already? [04:26] generic.c | 5 ----- [04:26] piix.c | 19 ++++++++++++------- [04:26] that's the diffstat for beta to now in drivers/ide [04:26] no [04:26] the generic.c change was actually to revert it back to stock (jmicron bug that delayed beta) [04:27] err, that should have delayed beta :) [04:27] we missed it for that milestone [04:27] Keybuk: I can't see how it wouldn't [04:27] does anyone want me to test parallels for the slowdown? [04:27] I don't think parallels got the piix reversion? BenC? [04:28] pkl_: it should have [04:28] I tried echo -n 0000:00:07.0 > bind as well, that didn't go either [04:29] shouldn't it be "ven dev", not ven:dev? [04:29] that's bind [04:29] I did echo 8086 7111 > new_id [04:29] oh, right, I get those mixed up [04:30] it don't like binding :) [04:30] maybe I need to force libata instead? [04:30] ata_piix is the one that has the PCI probe callbacks and device table [04:31] ah right [04:31] isn't playing anyway === Lure [n=lure@153.5.60.234] has joined #ubuntu-kernel [04:33] mdz: NOT A CRISIS: http://lwn.net/Articles/229690/ [04:33] Keybuk: thanks === rtg_ [n=rtg@gn-216-166-171-58.mtwireless.net] has left #ubuntu-kernel ["Ex-Chat"] === rtg_ [n=rtg@gn-216-166-171-58.mtwireless.net] has joined #ubuntu-kernel [04:44] I'm going to give ws6 a try again...wish me luck [04:44] BenC: gl [04:44] :-) === BenC_ [n=bcollins@collinsap1.phunnypharm.org] has joined #ubuntu-kernel [04:47] wont be trying this again [04:47] maybe my 64-bit vmware doesn't like 32-bit CD's === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel [04:48] 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] maybe I should disable it from using vmx too [04:48] pkl_: ven/dev for your chip? [04:49] 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] pkl_, /proc/version_signature [04:49] pkl_: cat /proc/version_signature [04:50] Thanks, -15.27. I put the ven/dev earlier, but I'll paste it again [04:51] parallels (MBP) 00:1f.1 IDE interface [0101] Intel Corporation 82801BA IDE U100 [8086:244b] [04:51] subsystem: Intel corporation unknown device [8086:4541] [04:53] pkl_: Boot with break=top, at the prompt, modprobe piix [04:53] exit, and see if things continue along happily [04:53] OK [04:53] cjwatson: do we have any dailies from before 20070412? [04:53] any isos at all? [04:54] (you'll get some dmesg after the modprobe if it worked) [04:56] BenC: if this isn't a piix regression, do you have any theories? [04:56] mdz: let me check drivers/block/ [04:57] nope, nothing there either [04:57] BenC, check block/ too [04:57] ah, right [04:57] 0 files changed [04:57] BenC: yeah, that worked fine. Cdrom recognised okay (obviously). [04:57] drivers/block has only ps3_storage.c changed [04:58] pkl_: can you check the apparent performance? [04:58] mdz: not unless they got released [04:59] 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] cjwatson: are you aware of any other changes which could have affected this? toolchain? livefs build process? buildd machines? [05:00] http://people.ubuntu.com/~bcollins/since-beta.diff [05:00] that's the diff of the entire tree since beta [05:00] I've looked over that [05:00] OK [05:00] as has Keybuk [05:00] we didn't spot anything out of sorts === Keybuk is reading -changes atm [05:00] except that it's enormous, of course [05:02] the only close-to-relevant CD build change I know of is that I dropped the hw-detect/start_pcmcia=false workaround [05:02] doesn't affect the live CD at all though [05:04] Keybuk, mdz: either of you tried vmware under windows host, to make sure the slow down isn't host side? [05:04] the host didn't change between the tests though? [05:04] and I've seen this on widely different hosts [05:05] ok, I'm going to have to go on the assumption that this isn't IDE/libata/DMA/piix/ata_piix related [05:05] so that leaves general performance problems [05:06] BenC: my host has been running dapper [05:06] the only way to prove otherwise is to bisect the kernel, always using piix driver, and see if that makes any difference [05:06] any other theories? anyone? [05:06] my vmware seems busted at the moment, but I guess I could get a ws5 image/lic real quick and start testing [05:06] anything goes at this point [05:06] BenC: or run an old kernel in a new image. [05:06] BenC: that would be a good idea [05:07] what's this "ACPI Drive" stuff? [05:07] oh, it's in ata/ [05:07] anyone tried disabling ide acpi yet? [05:07] hold a sec... [05:08] is i810 relevant? [05:09] hmm...what video is it using? [05:09] have all these tests been done with livecd, or any alternate testing? [05:09] just livecd [05:10] well, any video it's using most likely isn't using agp/drm, so there's no changes that should affect it [05:10] I'm installing a beta image, to test pure CD IO performance [05:10] was wondering whether the video dma changes could've mucked up IO dma [05:10] ide=noacpi is something else to try === johanbr [n=j@JBrannlund.MathStat.Dal.Ca] has joined #ubuntu-kernel [05:13] break=top, modprobe ide-core ide=noacpi [05:13] +Starting balanced_irq [05:13] BenC: no particular acpi changes [05:13] BenC: what's that? [05:13] probably has to be done that way [05:13] mdz: acpi is the only notable things in our drivers/ide/ that is not in upstream [05:13] BenC: what's balanced_irq? [05:14] mdz: it balances irq's on SMP systems [05:14] so other than just the first CPU can handle IRQ's [05:14] there was some updates to it to handle multi-core/shared cache a lot better [05:15] but I thought it was in universe [05:15] it is [05:15] i never put it in a MIR for it. [05:16] (since it was post-beta) [05:16] so it does nothing without the userspace bits installed? [05:16] anyone have a quick download for ws5 so I don't have to do this email song and dance? [05:16] (apart from mentioning itself in dmesg) [05:17] BenC: I have a copy here [05:17] can upload it to the DC quick [05:17] mdz: ah, balanced IRQ in kernel, it does some trivial balancing, but nothing major [05:18] BenC: ~mdz on chinstrap [05:18] ETA 5 seconds [05:18] mdz: thanks [05:20] need coffee and a smoke, and few minutes to ponder things at this point [05:20] afk for about 10 [05:29] hmm, beta is STILL installing! [05:31] one thing I didn't check is changes in pci quirks that might affect piix === marcin_ant [n=marcin@194.114.146.126] has joined #ubuntu-kernel [05:32] I can't get anything approaching reproducible numbers by timing raw /dev/hdc or /dev/scd0 reads in vmware [05:32] so far our only test cases are booting the live CD and installing in ubiquity [05:32] hmm, changes in combined mode [05:33] but that affects only Intel SATA I think [05:33] splits the pata drive off the combined sata/pata chipset into a separate func [05:34] then there's MSI, and toshiba/sis quirks [05:35] let me do this ws5 install and try to reproduce so I'm at least working with you guys [05:37] mdz: do you have fixed tarballs for the module source for vmware? [05:38] or do these build ok? [05:38] BenC: not on me [05:38] they wo'nt build, the fix is all over google though [05:39] I forget the name of the update file, do you remember it? [05:40] got it === marcin_ant_ [n=marcin@194.114.146.126] has joined #ubuntu-kernel [05:45] whatever the line that fails, comment it out [05:45] I can't get the key I pulled from wiki to work [05:46] did you pull it from the new page, instead of the old? [05:46] it was under Montreal/VMware or something [05:46] yes, the ones marked March 2007 + 180 [05:46] one of the keys didn't work, another one did [05:46] I'll not it on the wiki [05:48] ffs, the any-any gave me bad modules versions [05:55] BenC: is this the same machinew here you have ws6 installed? maybe they can't coexist peacefully [05:55] I uninstalled ws6 first [05:55] any-any was too old for this ws5 [05:55] so fixing the module source manually [05:56] ok, beta is STILL copying off the damned CD [05:58] (that's with ata_piix ...) === lamont [i=lamont@nat/hp/x-24f9c20f67f8b6b7] has joined #ubuntu-kernel === ivoks [n=ivoks@21-23.dsl.iskon.hr] has joined #ubuntu-kernel [06:00] 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] er, discount, not disconnect [06:01] how do you mean? === BenC_ [n=bcollins@collinsap1.phunnypharm.org] has joined #ubuntu-kernel [06:01] we can't get useful timings from the real cd [06:01] dear vmware, please stop crashing my system [06:01] since vmware's clock invents numbers [06:01] and a stopwatch gives different answers too === lazka [n=lazka@85-125-222-171.dynamic.xdsl-line.inode.at] has joined #ubuntu-kernel [06:07] anyone tried switching the cd to SCSI instead of IDE to see if that makes a difference? [06:07] not yet, am still waiting for this one to install [06:07] at which point I can have the VM back for a bit === cma-desktop [n=cma@r190-64-20-235.dialup.adsl.anteldata.net.uy] has joined #ubuntu-kernel [06:08] I'm going to install vmware on this other machine to see if I can get it to work === cma-desktop [n=cma@r190-64-20-235.dialup.adsl.anteldata.net.uy] has left #ubuntu-kernel ["Ex-Chat"] === dholbach [n=daniel@ubuntu/member/dholbach] has joined #ubuntu-kernel [06:15] has bug 106864 come up on this channel already? [06:15] it's unfortunately not too clear what's going on, only fragments of error messages [06:16] the comments from Arjan Kon are probably a different bug, but have more detailed results [06:16] looks like he fell to initramfs. [06:17] looks like the exceptions are ata_piix related [06:17] "oops, I tripped, and fell, and landed initramfs" [06:17] same as we saw in vmware [06:17] yeah they are the same [06:17] exceptions> Arjan's, right? === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === ^^CatTuX^^ [n=^^CatTuX@mbl-65-129-173.dsl.net.pk] has joined #UBUNTU-KERNEL [06:21] so, err [06:21] cjwatson: yeah [06:21] how do you get vmware to boot off an emulated scsi cd-rom? [06:21] Keybuk: the CDROM pref page for the VM should let you select IDE or SCSI [06:21] it did for me at least [06:21] yes [06:21] but how do you boot off it? [06:22] the bios doesn't seem to support that [06:22] uh, it should I guess [06:23] why? [06:23] you normally can't boot off scsi cdroms [06:23] not if there's a boot image on a scsi drive with a lower id === ^^CatTuX^^ [n=^^CatTuX@mbl-65-129-173.dsl.net.pk] has joined #UBUNTU-KERNEL [06:28] Keybuk: doesn't vmware have a Boot menu in bios? [06:29] yes [06:29] PC BIOS can only boot off things like IDE, remember [06:30] so "SCSI" tends to be a boot option :p [06:30] (booting current with piix and ide=noacpi didn't help) === defendguin [n=jmsunser@216-136-108-250.static.twtelecom.net] has joined #ubuntu-kernel [06:32] if the SCSI controller does the right BIOS setup, then the BIOS shouldn't care that it's a SCSI drive [06:33] s/drive/cdrom/ [06:44] 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. === mvo [n=egon@p54A67983.dip.t-dialin.net] has joined #ubuntu-kernel [06:45] tested 20070301, 20070313, 20070411 and 20070415 :) [06:45] 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] mvo: what is module wfb? [06:47] 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] It's an X module, not a kernel one [06:48] Is it in the package? If not, is it in the source package? [06:48] looks legit, so we may need to add it as part of the nvidia-glx-new package [06:49] mvo: I've taken it on [06:49] BenC: thats great, thanks a lot! === bleinmono [n=toffel@ppp91-76-75-204.pppoe.mtu-net.ru] has joined #ubuntu-kernel === btse [n=BTSE@c83-253-251-101.bredband.comhem.se] has joined #ubuntu-kernel [06:59] Keybuk: weird that they let you make it a SCSI device and don't let you boot from it [07:00] so what's our guage for this bug? [07:00] I just got to desktop after power on in less than 2 minutes with current livecd [07:02] Parallels takes 1:01 (iso on hard disk), no performance problems. [07:03] with latest livecd [07:04] BenC: try and install [07:04] starting an install for a more thorough test [07:05] system is using piix right now [07:05] note I'm on a 64-bit intel core2duo install, 32-bit vmware ws5 [07:05] oh wait, no, it's a 64-bit Turion x2 [07:07] I've seen the same on a dual 64-bit athlon x2, sata_nv etc. [07:10] BenC: what can we do to help you debug this [07:10] since performance in vmware is our prime feature for Ubuntu Server 7.04, this is of showstopper grade [07:11] ahci on the host [07:11] ? [07:11] my host for vmware is using achi, was just checking that [07:11] guest is using piix [07:12] BenC: vmware running on what? [07:12] Keybuk: At the moment, I'm unable to reproduce any real performance issue [07:12] both mdz and I are [07:12] Turion x2 [07:12] it took well over an hour to install here [07:12] Keybuk: what's your host you've been testing with now? [07:12] ICH7 [07:13] intel core duo [07:13] piix or ata_piix for disk? [07:13] I assume the latter [07:13] ata_piix === reitblatt [n=mark@resnet-50-180.dorm.utexas.edu] has joined #ubuntu-kernel [07:13] is a 1 hour install really that bad for a virtualized install? [07:13] 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] BenC: yes, given we've specifically press released that we have improved performance in vmware! :) [07:14] mvo: Nope, reject that one, we can't do anything about people clashing local installs with package installs [07:14] BenC: will do, thanks [07:14] Keybuk: how long does edgy take to install? [07:14] BenC: 10-15 mins max [07:14] 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] I don't recall ever getting an install that fast [07:15] feisty took 60-90 mins (I got so bored I did other things) [07:15] BenC: I can appreciate that you can't replicate the problem [07:15] pkl_: we are promoting our guest speed, so any host should be good [07:15] so what can mdz do to help you understand it? [07:15] mdz and I [07:15] Keybuk: I can't replicate your 10-15 minutes installs with edgy is the problem :) [07:15] BenC: how long do they take for you? [07:16] Keybuk: and besides, our "speed feature" is only in relation to ws6 and related products where paravirt is enabled [07:16] Keybuk: about an hour [07:17] the press release doesn't say that :-/ [07:17] the press release is quite lacking in information that I've provided then [07:17] what kind of VM did you use? [07:17] "Improved performance with as a guest under VMware using paravirtual ops" [07:18] Keybuk: I've been using ws6 for quite some time, in beta [07:18] this is 256MB / 8.0GB ide / CD-ROM bound to file / 2 processors [07:18] 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] didn't you just say you tested on ws5? [07:18] Keybuk: I did all default, so 256Meg, 8G, CDROM to file, single CPU [07:19] Keybuk: I just tested a feisty RC on ws5 [07:19] and it booted in around 1m30? [07:19] with no noticeable lag drawing the desktop? [07:19] yep [07:20] weird [07:20] the install is 15 minutes in, and at around 47% copying files === blueyed [n=daniel@i5387DE73.versanet.de] has joined #ubuntu-kernel [07:21] ruh roh [07:21] power may be going [07:22] if I drop, it may be 20-30 minutes before I get gen up and running [07:22] Keybuk: let's get some info out here to compare why things are slow for you and mdz and not for me [07:23] mdz is running on a dapper host [07:23] mdz: what sort of machine is it? [07:23] video, hd, etc. [07:23] Keybuk: one thing I didn't do on my VM was setup networking...so that's a datapoint right now [07:23] Keybuk: have you tried single cpu yet? [07:24] for guest [07:24] doing a dapper install now [07:24] to test [07:24] yeah, single cpu was same problem [07:24] I tried double to see whether that fixed it [07:25] I'll give you a third data point at some point after dinner [07:26] is nvidia-glx-new on the CDs? [07:29] BenC: I've only been able to test on this dapper amd64 box [07:29] mdz: is it running 32-bit or 64-bit on host? [07:29] BenC: did you compare with beta, or with ws6? [07:29] and are you testing 32-bit or 64-bit guest? [07:29] 32-bit guest on 32-bit host for me [07:29] BenC: it's running a 32-bit kernel [07:30] 32-bit guest [07:30] (same problem seen with 32-bit guest on 64-bit host) [07:30] just happens to be a 64-bit cpu [07:30] I have 64-bit host, but 32-bit ws5 and 32-bit guest [07:30] so it _should_ be the same [07:30] I assume my 64-bit host was a 64-bit ws5, since it can host 64-bit images [07:30] mdz: can you really get 10-15 minute installs of edgy? [07:30] BenC: and were you able to measure a difference from beta->rc? [07:30] (how does one tell?) [07:31] BenC: I'm half way through a dapper install, 9m gone, 9 to go [07:31] BenC: I can do one right now and time it... [07:32] Keybuk: I think guest support is only limited by kernel/vmmon, so it might still be a 32-bit vmware [07:32] Keybuk: file /usr/local/bin/vmware [07:32] see if it's elf 32 or 64 [07:33] let me get an edgy iso to see if I can get this super speed install [07:33] 54%, 6:08 remaining [07:33] (edgy boots the live CD in 1:07 fwiw) [07:34] /opt/vmware/vmware: Bourne shell script text executable [07:34] <> [07:34] can you guys check your bogomips between edgy and feisty? [07:34] /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] ok [07:34] BenC: inside vmware or outside? [07:34] Keybuk: ok, same as me then [07:34] Keybuk: in vmware [07:34] that's in dmesg right? [07:35] or /proc/cpuinfo [07:35] [ 18.818982] Calibrating delay using timer specific routine.. 2403.75 BogoMIPS (lpj=4807513) [07:35] ^ cupprent [07:35] [ 49.406032] Calibrating delay using timer specific routine.. 2380.15 BogoMIPS (lpj=4760307) [07:35] ^ beta [07:35] ubuntu@ubuntu:/mnt/var/log/installer$ sudo grep ubiquity syslog |head -1 [07:35] Apr 12 13:11:25 ubuntu ubiquity[6131] : Ubiquity 1.2.5 [07:35] ubuntu@ubuntu:/mnt/var/log/installer$ sudo grep ubiquity syslog |tail -1 [07:35] Apr 12 13:27:11 ubuntu ubiquity: Purging configuration files for libglibmm-2.4-1c2a ... [07:35] ^^^ 6.10 final [07:35] [17179573.224000] Calibrating delay using timer specific routine.. 2406.73 BogoM [07:35] IPS (lpj=4813470) [07:35] ^ dapper [07:37] ubuntu@ubuntu-desktop:/var/log/installer$ sudo grep ubiquity syslog |head -1 [07:37] Apr 16 09:46:25 ubuntu ubiquity[8750] : Ubiquity 1.4.11 [07:37] 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] ^^ current feisty [07:38] so 16 minutes vs. 25 [07:39] mdz: so feisty took 25 minutes to install and edgy took 16? [07:39] What's the difference on real hardware? [07:40] unknown, I just had those numbers around [07:40] the real difference I saw was between the 11th and 12th [07:40] both in vmware [07:40] unfortunately we've deleted those isos [07:41] mdz: was that perhaps when we went from piix to ata_piix? [07:42] BenC: yes [07:42] er [07:42] no, the other way around [07:42] from ata_piix to piix [07:42] dapper install finished: 21 mins [07:42] how could you notice a problem when ata_piix wasn't even working for you? [07:43] s/problem/slow down/ [07:43] wasn't working for atapi at least [07:43] or did you notice a general problem in an existing system when we did the switch [07:43] existing VM that is [07:46] Ok, edgy iso booted in about the same amount of time for me [07:47] starting the install === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel [07:48] wow, I think my guest clock just went backwards [07:48] they do that [07:48] I could have sworn I saw it go 1:48 to 1:47, then to 1:48 again [07:48] I like mdz's demo that sleep 10 sleeps for an amount of time that will never equal 10s [07:48] I'll watch the host clock [07:48] a watched clock never boils [07:49] hopefully, neither does an unwatched one :) [07:51] BenC: the clock is very funny, I don't really trust those numbers in syslog [07:51] BenC: ata_piix was functional for me, it just spewed a huge volume of scary errors while it worked [07:51] mdz: even for atapi it worked? [07:51] I'm open to the idea that Keybuk and I are both hallucinating [07:51] BenC: yes, I was only using it for atapi [07:52] hmm [07:52] I use the standard default ubuntu config in vmware, which is a SCSI (LSI) HDD and ATAPI (PIIX) CD-ROM [07:52] but while I'm open to the idea, someone needs to independently demonstrate that we're crazy [07:52] because so far our results are consistent with each other [07:53] my boot times for edgy/feisty under vmware are only off by a few seconds...they are virtually (heh) the same [07:53] the install times I'm checking now [07:53] which feisty? [07:53] BenC: booting the CD or booting from HDD? [07:53] latest ISO, 15.27 kernel [07:54] mdz: booting the live CDs [07:54] BenC: ok, that's very interesting [07:54] so, I'm trying a random test [07:54] this clock skew on vmware really worries me [07:55] booting different livecds and moving 8GB from a SCSI disk to an IDE disk and back again [07:55] it's already 6 minutes ahead of my host [07:55] BenC: I see that too, though I think I probably always have [07:55] mdz: I'd say the syslog times you pasted are probably bad data points for this [07:56] maybe vmware is going so fast, it's slowing down time [07:56] (and thus installs) [07:56] mdz: any chance you can do installs and check your host times for comparison? [07:56] BenC: I agree [07:56] but Scott's are wall clock timings [07:56] I'm going to do a test in a second [07:56] ie. I timed it with a stopwatch [07:56] however this is on a Debian host as I've never migrated that vmware install [07:57] cjwatson: my host has been neutral throughout; I don't suspect any problem on the host side [07:57] Keybuk: from pressing enter at the CD boot prompt, or from vmware boot? [07:57] cjwatson: hard to muddy the water any more than it is :) [07:57] cjwatson: I did CD prompt to icons showing up [07:57] cjwatson: from pressing ^D at break=top after manually loading piix and making sure it was bound [07:57] FWIW, I'm on 5.5.1 [07:57] Keybuk: on -15.27 kernel feisty, piix most certainly is bound [07:58] for beta iso's, you need the break [07:59] for installs, I'm timing from the last screen in ubiquity to the "restart" dialog === BenC watches vmware go back 9 minutes in time [08:00] 5.5.2 build-29772 here [08:00] amd64? [08:00] and BenC's using my tarball [08:00] kylem: amd64 running 32-bit kernel/userland/guest [08:00] feisty boots in 1:28 [08:00] sorry, i should say "athlon64" [08:00] i mean, is it an amd chip [08:00] yes [08:00] see, colin's getting what I'm getting for feisty [08:01] dual core amd has unsynched tsc. [08:01] model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ [08:01] will take a few minutes for edgy to copy across from my server [08:01] so if vmware is using the tsc to get the clock, it will flip back and forth and lose (or gain) ticks [08:01] mine is turion x2 as well [08:01] my vmware clock always runs slower than my host clock [08:02] mine is single-core Athlon64 [08:02] and it's a dual-core Intel [08:02] fairly old, summer 2004 I think [08:02] Keybuk: weird, on this box, mine always runs faster :) [08:02] so Keybuk is the only one testing on an Intel host right now [08:02] hmm [08:02] but we have UP and SMP covered [08:03] ok, wall clock time on my edgy install was 15 minutes [08:04] that's from pressing Install button on summary page to final dialog appearing? [08:04] Ubuntu in Parallels also runs slower than the host clock. === Keybuk is still waiting for the feisty CD to book [08:05] boot too [08:05] cjwatson: yes [08:05] (feisty took a weirdly large amount of time to get to usplash, btw - maybe 20 secs) [08:05] which is Intel obviously. [08:05] edgy boots in 0:52 [08:06] unfortunately I don't have feisty beta handy - will take c. 2 hours to download [08:06] so noticeably slower, but possibly due to more services? [08:06] kicked off a download [08:06] I think most of that was the pre-usplash delay [08:07] I need to do these boot tests on a real machine between edgy/feisty [08:07] which could easily have been something kooky in initramfs [08:07] unless someone else wants to do it [08:07] why don't I kill the beta download to avoid stray i/o and do install time tests [08:07] there's really no need to mess with edgy [08:07] the difference can be seen from beta->rc [08:07] I don't have beta handy [08:07] yes, but I have edgy here and not beta [08:07] but I guess I can download it [08:08] the need to mess with edgy is getting results now instead of in two hours [08:08] but the results may not be particularly meaningful [08:08] absence of regressions from edgy is meaningful enough to me [08:08] mdz: ish, beta does take a long time to install for me :-/ [08:08] edgy is worth testing [08:09] and is equally worthwhile [08:09] if we can get a definitely reproducible useful test, we can track forward [08:09] more than "boot time"/"install time" [08:09] anyone tried bonnie++ or similar? [08:10] pre-usplash delay> oh, I bet that's console-setup [08:11] BenC: interesting timing here [08:11] though it should be working with pregenerated files [08:11] hdparm -t on an IDE disk in vmware [08:11] dapper: 1800 MB/s [08:11] so I don't quite get why it would be so slow [08:11] current: 750 MB/s [08:11] oooh [08:12] Keybuk: is it reproducible many times? [08:12] yes [08:12] the numbers are pretty consistent [08:12] worry about the guest clock skewing things [08:12] hdparm -T is probably more realistic [08:12] yeah, given the guest clock skew, that's unconfirmed [08:13] -T doesn't measure throughput to the disk though? === gortiz [n=gortiz@88.87.105.4] has joined #ubuntu-kernel [08:13] mjg59: 75 MB/s vs. 35 MB/s [08:13] it's a more realistic system test, but the disk controller driver is the suspect component here ... [08:13] cjwatson: it's been difficult to do benchmarking inside the VM because the clock is fucked [08:14] there's gotta be a way to do this [08:14] something that took a stopwatch-measurable amount of time to do each test would be good enough [08:14] vmware was doing micro and macro benchmarks reliably [08:14] cjwatson: -t is also testing the vm system [08:14] cjwatson: for i in `seq 20`; do dd if=/dev/hda; done and using a stopwatch should work. [08:14] mjg59: "performance problems in vmware" could also be the vm system, though I doubt it [08:15] -T does buffer cache which doesn't seem especially useful or relevant [08:15] Mithrandir: dd to where? [08:15] Keybuk: /dev/null? [08:15] in particular it explicitly says "without disk access" [08:15] Oh, sorry - I had those the wrong way round [08:16] Though the timings would seem more consistent with them being the way I thought... [08:16] mm [08:17] cjwatson: I believe that means 'without physical disk reads' not 'without communicating with the disk' [08:17] oh, I'm wrong [08:17] mdz: in context, it's talking about buffer cache and says it deliberately avoids measuring disk performance [08:17] "This displays the speed of reading directly from the Linux buffer cache without disk access." [08:18] comparison from my laptop: [08:18] Timing cached reads: 814 MB in 2.00 seconds = 406.48 MB/sec [08:18] Timing buffered disk reads: 84 MB in 3.01 seconds = 27.89 MB/sec [08:18] that would make sense. [08:19] 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] Mithrandir: 3:41.1 in feisty current [08:19] Keybuk: ugh. [08:19] oddly enough, vmware's clock matches stopwatch there [08:19] hmm [08:19] Keybuk: how big a disk? [08:20] 8GB [08:20] oh, and fragmented or solid? [08:20] (whatever you call the non-fragmented thing - single-file?) [08:20] 2GB chunks [08:20] preallocated? [08:20] yeah [08:20] not actually allocated though [08:20] since the disk is "empty" [08:20] so this shouldn't touch the host disk hardly at all [08:20] I have limited disk space so I always use chunks [08:24] feisty install is definitely noticeably slow for me than edgy [08:24] 12 minutes into it, and it's only at 50%, still copying files [08:24] will tell you my result there in a moment [08:24] guess I better get beta [08:25] mdz, Keybuk: so beta was ok, and current is slow, that's your test case right now? [08:25] BenC: I have my doubts about beta [08:25] current is definitely slow [08:25] ah, right, beta was still slow for you [08:25] I don't get consistent results from hdparm at all, which is unsurprising to me given the clock skew [08:26] BenC: beta is better here [08:26] wall time on dapper for the dd test, 02:39 [08:26] I installed dailies in vmware all last week, and noticed the difference on thursday [08:26] but I am at a loss to provide particularly believable numbers [08:27] mdz: do you have the same dailies around? [08:27] BenC: nope [08:27] they were deleted over the weekend, while I was dealing with my hosed laptop [08:28] mdz: given a kernel image just before the ata_piix/piix switch, can you regen an ISO from current using that image? [08:28] BenC: that should be possible, yes [08:28] http://www.vmware.com/vmtn/resources/238 [08:29] 14.22 was just before the switch [08:31] damnit, the .deb's are gone from lp [08:31] err, shouldn't be [08:31] for the broken one they were nuked, no? [08:31] I'll find them [08:31] not from the librarian, no [08:31] ah. [08:31] they're just hard to find [08:32] you have to go to the "builds of" portlet [08:32] http://librarian.launchpad.net/7122345/linux-image-2.6.20-14-generic_2.6.20-14.22_i386.deb [08:32] great, ws5 killed my other box now [08:32] flashing led's [08:32] feisty installs in 8:44 (I think, pressed the wrong stopwatch button) [08:33] a lot faster than mine [08:33] 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] I'll try the dd test with fresh disks in a moment [08:35] BenC: they still seem to be there to me: https://launchpad.net/+builds/+build/315769 [08:36] 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] yeah === OldKid [n=oldi@fresno121.webperoni.de] has joined #ubuntu-kernel [08:39] anyone have the piix dev id for vmware handy? [08:39] Keybuk: how many dd iterations was your 3:41.1 timing above? [08:39] BenC: 8086:7111 [08:39] thanks [08:40] 06:31 < mdz> http://people.ubuntu.com/~mdz/temp/lspci-vmware [08:40] BenC, you'll want subvendor/subdevice too if you're going to blacklist it from one of the modules. [08:41] force probing ata_piix with new_id [08:41] cjwatson: just one [08:41] see if the install is any faster [08:43] about 2:50 for the dd test, 50.6 MB/s according to vmware's clock which seems more or less right [08:43] Keybuk: did you try dd from the cdrom? [08:44] cjwatson: that's what I'm trying now [08:44] still waiting for current to boot [08:45] 'cos my timing is not all that far off yours [08:45] 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] feisty dd if=/dev/hdc of=/dev/null: 33 seconds [08:46] 1430344+0 records in [08:46] 1430344+0 records out [08:46] 732336128 bytes (732 MB) copied, 115.963 seconds, 6.3 MB/s [08:47] (hdc -> null on dapper, 5x that one's pretty representative, there wasn't much deviation) [08:47] quite a lot slower [08:47] oh, dapper? hmm [08:47] unused to your machine just sucking compared to mine ;-) [08:47] it's only a laptop [08:47] ah [08:48] thought it was the 10-second booter or whatever it was [08:48] nah, that's at home [08:48] far too heavy to lug on skates [08:50] edgy dd hda: 1:23, twice as fast as feisty [08:50] cjwatson: wallclock time? [08:50] yes === BenC kicks new_id [08:50] I must admit, that my wall clock and my vmware clock match [08:50] mine too [08:50] Keybuk: you're uniprocessor [08:50] I've worked out why vmware's clock is different, it ran ntpdate ;) [08:50] both of you are [08:50] mdz: dual core [08:50] just intel not amd [08:51] edgy dd hdc: 28 seconds, smidge faster than feisty [08:51] that explains why install tests showed no difference, the CD hasn't changed much [08:51] ok, that was interesting [08:51] let me just repeat that test before I say about it [08:52] mm, I'm going to repeat my dd tests too === cjwatson stops bothering with the stopwatch [08:54] I just stopped bothering [08:54] and then noticed something [08:54] in feisty my wall clocks *are* different to vmware's clocks [08:55] in dapper they matched [08:55] bah, ata_piix doesn't support hotplug of controllers [08:55] wish there was a way to atomically add new_id during module init === BenC considers binary patch the driver in initramfs [08:57] hmm, dd giving comparable results for me too [09:00] 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] heno: what's the time for feisty on vbox? [09:01] BenC: 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] those times can be accounted for by things other than a kernel bug, I think [09:02] interesting, but still inconclusive [09:02] heno: which driver is used for the CD-ROM there? [09:02] heno: thanks for the testing [09:02] IIRC, it's piix as well, probably same 8086:7111 [09:03] is it at all possible that these times could be squashfs related? [09:03] mdz: can you tell me how to find out? [09:03] heno: lspci -vvnn | grep IDE [09:04] BenC: the squashfs update was much earlier, no? [09:04] pkl_: any reasonable potential for a performance regression there? === Keybuk is trying if=/dev/hdc of=/dev/sda1 [09:06] 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] how can it not show in the changelog? [09:07] it's automated :) === bronson [n=bronson@66.237.74.66.ptr.us.xo.net] has joined #ubuntu-kernel [09:09] that's odd [09:09] if we go by dates, then it had to be either in -12.19 or -12.20 === doko [n=doko@dslb-088-073-122-210.pools.arcor-ip.net] has joined #ubuntu-kernel [09:10] you don't have it tagged in git? [09:10] (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] BenC: it's not there [09:10] cjwatson++ [09:10] commit 01c7ecb34704df7feae2532006169786642f8fdd [09:10] Author: Phillip Lougher [09:10] Date: Fri Mar 16 14:02:58 2007 +0000 [09:10] UBUNTU: Squashfs: update to 3.2-r2 [09:10] Signed-off-by: Phillip Lougher [09:10] makes it much harder to scan the changelog [09:11] yes, I can that :) [09:11] ok, interesting [09:11] $ gzip -9c debian/changelog | wc -c [09:11] 79301 [09:11] (also) [09:11] $ grep -v GIT-SHA debian/changelog | gzip -9c | wc -c [09:11] 63093 [09:11] dd if=/dev/hdc of=/dev/sda1, wall time was 11:50, clock time was 543s [09:11] It was in -12.19 [09:12] Grep the changelog for Squashfs... first entry 26 Oct 2006 === jorge_pt [n=jorge@84.91.68.198] has joined #ubuntu-kernel [09:12] and yet the tree clearly shows that the diff is applied [09:12] 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] git-log Ubuntu-2.6.20-11.18..Ubuntu-2.6.20-12.19 [09:13] shows it [09:13] mdz oddly lspci -vvnn didn't give me that info, but Device Manager tells me PIIX_IDE [09:14] it would be nice if there was a quick way to see what kernels were in what milestone [09:15] BenC: is it possible the scripts didn't like Phillip's (none) hostname? [09:15] although later changes from pkl do show up [09:15] 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] cjwatson: previous commits show up, even though the hostname had the same problems. But, I noticed the none hostname and fixed that. [09:17] 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] 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] cjwatson: that command misses his entry, so I'll have to check why [09:19] 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] 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] yeah, I think chances are thet squashfs is a red herring myself [09:22] that [09:23] pkl_: we're having problems pointing the finger at anything, so squashfs got dragged in [09:23] pkl_: is there an easy test we can do from livecd to see squasfs performance comparisons? [09:24] like find /usr | time xargs cat > /dev/null ? [09:24] Ah, I don't mind. Squashfs is an obvious candidate, and I've been trying to think of potential issues all day :) [09:24] Yes, there's two potential cases. Dentry performance is slower, or readpage performance is slower... or both. [09:25] Doing a find with an option requiring a stat of each inode (i,e, -type f), will test dentry regressions. [09:25] find | xargs has the problem that it also stresses CD seek times [09:25] might not matter in vmware of course [09:26] only a virtualized ISO, probably not much of an issue [09:26] maybe read a big file out of the squashfs instead [09:26] 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] no file data reads, that is. [09:27] biggest file on the squashfs is /usr/lib/libgcj.so.70.0.0 - only 30MB though [09:27] ("only". damn gcj.) [09:27] I keep thinking we need a sane way to go back and forth between piix and ata_piix using the same CD [09:27] doesn't openoffice have one bigger? [09:28] this is from "find /rofs -type f -printf '%p %s\n' | sort -k2 -nr | head" [09:28] so no [09:28] ata_piix doesn't support new_id [09:28] piix does though [09:28] OOo doesn't come in until no. 7 [09:28] 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] TBH, this is all pressing my "release-critical" buttons less and less convincingly [09:30] cjwatson: agreed [09:30] though I think it is still worth the detailed investigation [09:30] 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] anyway, speaking of focusing, it's 8:30pm and I'm off to play Lego Star Wars or something :) [09:31] heh [09:31] 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] pkl_: is 30MB likely to be large enough, or would we need a custom squashfs? [09:32] cjwatson, mdz: I do need to make an lrm upload to fix nvidia-glx-new [09:32] dd tells me 27.2 MB/s first time round, and thereafter c. 200 [09:32] It doesn't affect linux-restricted-modules-* at all [09:32] I'm not sure, but looking at the slowdown, it should be measurable over 30MB. [09:32] (feisty [09:32] ) [09:32] just that one package (so doesn't bother CDs) [09:33] pkl_: given vmware's clock fuckage, it may not be enough to be reliable :/ [09:33] Yeah, that's why I abandoned Parallels and Vmware for Squashfs development. [09:34] Couldn't reliably tell why affect changes had made .... [09:34] why -> what [09:37] I would be interested in why my laptop is crashing with ws5 and ws6 though [09:37] BenC: beg pardon? [09:37] BenC: what's wrong with it? [09:38] mdz: nvidia-glx-new is missing a file that wasn't in the other versions of nvidia [09:38] xorg module [09:38] BenC: so it's non-functional? [09:39] sounds like an SRU candidate if so [09:39] BenC: isn't nvidia-glx-new on the CDs? === Mithrandir thought it was [09:39] I don't know if nvidia-glx* is on the CDs [09:39] I didn't think they were [09:39] https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/103050 [09:39] there's the bug [09:39] Adding nvidia-glx to CD 1 ... [09:40] not -new, it seems, though [09:40] nvidia-glx is explicitly seeded, but not -new [09:40] is -legacy? [09:40] not an issue for installs or upgrades -> -updates [09:40] -legacy was deliberately unseeded at one point [09:40] BenC: doesn't look like it, no. [09:40] cjwatson: because we can't even pretend to give security support for it. [09:40] AIUI [09:40] indeed [09:41] supported: * Extra-Exclude: nvidia-glx-legacy-dev # nvidia-glx-legacy is unsupportable [09:41] we can't for nvidial-glx{,-new} either :) [09:41] we should probably invent a better name for nvidia-glx now that the package isn't maintained any more either. :-/ [09:41] BenC: we can pretend for -new [09:41] according to ATI it is [09:41] at least that [09:41] 's what they keep posting on the forums [09:41] uh, ATI? You mean nvidia? [09:41] I'm going to find food and then go home [09:41] err, I mean nvidia, yes :) [09:42] I have a functional laptop now though, so I should be back [09:42] I'd be very surprised if ATI supported nvidia-glx. :-P [09:42] mdz: have a good evening [09:42] hehe [09:42] 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] BenC: but, sure -new is fine since it doesn't touch the CDs. [09:42] though I've seen no indication other than hot air [09:43] Ok, upload should be quick and painless [09:43] Mithrandir: an l-r-m upload would create skew though [09:43] cjwatson: ugh, true. :-/ [09:43] BenC: iirc -legacy at least has known root holes? [09:43] if that concerns you for update-manager ... [09:43] vmware-tools should mitigate clock skew [09:43] cjwatson: it does. [09:43] but if want to respin anyway.. [09:44] I think I'm with mdz if it doesn't affect new installs or upgrades from dapper/edgy [09:44] Mithrandir: I don't think so anymore...although they have been release non-frequent updates to that line of the driver [09:44] BenC: ok [09:44] cjwatson: which way is that, SRU? [09:44] yeah [09:44] cjwatson: what about the update-manager one? [09:44] works for me [09:45] Mithrandir: no opinion yet, haven't read enough of it [09:45] BenC: if so, the bug should be milestoned later so we don't forget [09:45] ok, tell me if you need anything for it. [09:45] er, "later" [09:45] which is an edgy milestone. LP should grow the ability to either move milestones between releases or have distro-wide milestones. [09:45] We have one Ubuntu:later [09:45] is that edgy? [09:45] yes, but just use that one. [09:46] ok, done [09:46] only LP cares that it's edgy. === Shoaibi [n=^^CatTuX@mbl-65-129-173.dsl.net.pk] has joined #UBUNTU-KERNEL === Shoaib [n=^^CatTuX@mbl-65-129-173.dsl.net.pk] has joined #UBUNTU-KERNEL === Shoaibi [n=^^CatTuX@mbl-65-129-173.dsl.net.pk] has joined #UBUNTU-KERNEL === bronson_ [n=bronson@66.237.74.66.ptr.us.xo.net] has joined #ubuntu-kernel === ^^CatTuX^^ [n=^^CatTuX@mbl-65-129-173.dsl.net.pk] has joined #UBUNTU-KERNEL [10:01] Copying the contents of an alternate CD to HD (virtualbox) on Edgy: 1:15, on Feisty: 1:10 [10:01] so if anything, slightly better CD performance of Feisty [10:12] heno: Contents as opposed to dd'ing the device image, right? [10:12] BenC: right, nautilus copy+paste [10:13] sounds reasonably close then === Lure [n=lure@ubuntu/member/lure] has joined #ubuntu-kernel === Mirrado [n=Mirrado@200.128.80.254] has joined #ubuntu-kernel === cox [n=cox@client-81-107-200-114.glfd.adsl.virgin.net] has joined #ubuntu-kernel [10:27] Hi, where is the write place to submit a error with the last proposal to final version of the Feisty kernel? [10:27] Mirrado: launchpad.net/bugs [10:30] I already created the bug in launchpad (bug #75935). That is enough? [10:30] Yes [10:30] mjg59: thanks === ivoks [n=ivoks@17-147.dsl.iskon.hr] has joined #ubuntu-kernel === lazka [n=lazka@85-124-173-179.dynamic.xdsl-line.inode.at] has joined #ubuntu-kernel === blueyed_ [n=daniel@i5387D127.versanet.de] has joined #ubuntu-kernel === stgraber [n=stgraber@ubuntu/member/stgraber] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === Mirrado [n=Mirrado@200.128.80.254] has left #ubuntu-kernel [] === cypherdelic [n=cypherde@port-87-234-141-130.dynamic.qsc.de] has joined #ubuntu-kernel [11:00] feisty wont beat 2.6.21, right? [11:00] Feisty will be shipping 2.6.20 [11:01] so 2.6.21 will never be available for feisty? === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [11:03] i'm sure you'll find a tutorial on ubuntuforums to get a running .21 kernel pretty soon [11:03] so that would'nt be an issue [11:03] We'll probably be skipping to .22 for gutsy [11:04] right [11:04] i meant untill gutsy kicks the shelves :) [11:04] yes that would best, 6 month, hmm maybe ,23 [11:04] .23 is unlikely [11:04] Given that .21 isn't out yet [11:05] its rc7, torvalds doesnt want a rc7 [11:05] its nearly released [11:12] it might be nearly released [11:12] but it's not tested enough to get to a stable april release, IMO [11:13] 99% chance we'll be .22 [11:13] that's why i said it could catch a nice compilation tutorial on the forums [11:13] 0.05% chance of .23, and 0.05% chance of .21 [11:14] BenC: Dude, that's 99.1% [11:14] BenC, so you're saying another kernel update is upon us ? [11:14] ok, 0.9% that we'll move to a hurd kernel [11:15] MrNOKIA: For gutsy [11:15] MrNOKIA: for feisty, there are no more kernels [11:15] Well, other than updates [11:15] except for security and maybe some driver updates === kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu] has joined #ubuntu-kernel [11:15] i was pretty sure of that :) [11:16] it seems there's an (minor ? ) issue with ati detection on the RC, according to the thread [11:17] what thread? [11:17] yes yes more nvidia bug fixes [11:17] 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] http://ubuntuforums.org/showthread.php?p=2464356#post2464356 [11:17] post #12 [11:17] BenC: And the ACPI stuff, but yes [11:18] mjg59: the "extended" acpi... [11:18] for just libata...ide-acpi is all good? [11:19] Yeah [11:19] MrNOKIA: almost no info there...don't know if he's using ati or fglrx [11:19] don't know how it breaks either [11:20] likely not a kernel bug, so my stress level is constant (still high, but level) [11:21] cjwatson: I know rtg had some weird ati bug with the dell 1505 he has [11:21] cjwatson: Still do. [11:21] install wouldn't work even for vesa graphics on the livecd, but after an install with alternate it went ok [11:21] rtg_: was yours a 200M? [11:21] BenC: Not true. I had to install fglrx. [11:22] ah, that's right [11:22] ATI X1300 [11:22] we killed colin [11:22] poor guy. [11:22] :) [11:23] there's one thing i don't get === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel [11:24] are there instances where it might work beryl on a live cd ? [11:24] 945/965 graphics will work out of the box...some older ati cards work with xorg driver [11:24] i try to understand why it has been included on the livecd [11:24] mine is ati x1400 on my laptop [11:25] it doesn't work at all [11:25] "some older ati cards" [11:25] same for an nvidia 5500 card [11:25] i got it [11:25] obviously most laptops wont work [11:25] a lot of mine do, because I've preferred intel graphics lately [11:26] I don't get 23 billion fps with glx gears, but it runs nicely :) [11:27] i found my dell to be a best buy when it appeares [11:27] appeared [11:27] the only issue is the ATI card [11:27] if I buy anything right now, it's going to be core2duo with intel graphics [11:27] ipw3945 wireless [11:28] best platform for open source right now...only drawback is the ipw3945d userspace daemon [11:28] but i hope someday ATI will realize tha it has to consider linux [11:28] have a friend who worked there in the driver departament [11:28] he says linux doesn't matter for them very much :( [11:29] doesn't matter what the driver guys want...it's who's buying the cards that matters [11:29] i know... [11:30] 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] maybe AMD will have a say in the matter [11:31] let's hope for the best :) === defendguin [n=jmsunser@216-136-108-250.static.twtelecom.net] has left #ubuntu-kernel [] [12:03] it seems there's more kernel trouble on reiserfs [12:03] here http://ubuntuforums.org/showthread.php?p=2464356#post2464356 [12:04] what output could be helpfull in this situation ?