[00:10] <BenC> steph7: if you blacklist something it should not cause anything
[00:11] <steph7> thanks BenC for your reply
[00:12] <steph7> BenC, do you think it need to edit rc.conf and add rfkill unblock all?
[07:36]  * apw yawns
[07:47]  * _ruben concurs
[07:53] <ppisati> morning *
[08:00] <Fudge> query: why would speechd-up refer to kernel-patch-speakup as a recommended package when speakup is now in the kernel
[08:01] <apw> Fudge, out of date user-space perhaps
[08:03] <cking> morning apw
[08:03] <Fudge> think dependencies havnt been reviewed? well thats what i thought anyway. same with speechd-up how it goes and fetches festival stuff when espeak is already installed
[08:03] <apw> cking, moin
[08:04] <Fudge> moin to hust
[08:04] <smb> morning .+
[08:04] <Fudge> oops hust is hate
[08:05] <Fudge> think i wanted vich or something :$
[08:05] <Fudge> to much ranstein
[08:05] <smb> m?
[08:06] <apw> sounds like someone typing on an android keybaord to me
[08:06] <Fudge> i was trying to say good morning to you but screwed up
[08:06] <Fudge> oh android, i use a talkback keyboard on that but its slow, or i am 
[08:07] <apw> heh i was more referring to the 'random' words that the android spell checker likes to pick, and which you never notice before hitting send
[08:07] <smb> apw, And good keyboard not even helps against having the wrong language active on the spell checker
[08:08] <apw> yeah i don't envy you using two on there, i have enough trouble with just .en
[08:08] <apw> en_gb even
[08:08] <Fudge> i just dont know how to use the text prediction, the speech does not tell me the suggestions
[08:09] <apw> the interface is very busy, i suspect it'd never shut up if it did
[08:09] <smb> Fudge, It is more us using the soft keyboard with big fingers and somethimes the wrong language. :)
[08:09] <Fudge> loL
[08:09] <Fudge> i was asked at work the other day to trial an iphone 4S so hopefully that comes through
[08:10] <apw> heh if anyone has done it right its them, or at least they have a patent on doing it right
[08:10] <Fudge> thats why i got my droid phone coz i couldnt borrow an iphone to play with voiceover on it. no one wants to part with their life lines
[08:11] <apw> oh a totally personal front i would love to hear if you find it workable
[08:11] <Fudge> apw  that was to me?
[08:12] <apw> Fudge, yep, i am interested to know if either is a workable device in that mode
[08:13] <Fudge> let you know mate
[08:13]  * cking sees what happens if he uses the precise kernel...
[08:14] <apw> cking, rtg was reporting positive results
[08:14] <smb> apw, You mean it boots?
[08:14] <cking> testing on UEFI boxen
[08:14] <apw> smb, remebmer we are at 3.1 final at the moement, so its in one of its better phases
[08:15] <cking> wow
[08:15] <cking> i915 now works
[08:15] <smb> Right
[08:17] <cking> 3.1 fixes my UEFI video issues, yay
[08:18] <apw> cking, i915> which aspect now works ?
[08:18] <cking> I can see something
[08:19] <smb> Thats because you had coffee
[08:19] <cking> before I just has a white noise line on the left of the monitor 2 pixels wide
[08:19] <cking> now I have perfect image
[08:20] <apw> cking, in bios or booted
[08:20] <cking> booted
[08:20] <apw> woh, thats not good
[08:21] <smb> cking, So UEFI would provide diplay information somehow?
[08:21] <cking> yeah, typing w/o any console feedback was a bit painful
[08:21] <cking> smb, no idea what was wrong, too many variables 
[08:22] <smb> cking, Likely right, and you probably only used UEFI boots on that hw
[08:22] <smb> So we would not know if compat bios would act differently
[08:22] <cking> yep, this is a non-CSM firmware image
[08:23] <smb> Could just be another case of needing to do things differently for a specific i915 type
[08:23] <cking> the funny thing was that control was not working in grub for some reason, bit hard to do emacs like editing in grub w/o control
[08:23] <apw> ctrl> heh that is a bit of a problem
[08:24] <cking> smb, well, we've seen other non-CSM UEFI firmware not work, so I need to sanity check these boxes next, when I get a spare moment or two
[08:24] <smb> cking, True
[08:27] <Fudge> completely offtopic here, but i read once from an opensolaris thread i think about actually being able to get some kind of text to speech in a grub menu. anyone ever heard of that? donno how there would be sound support but!
[08:30] <apw> Fudge, not heard of it, but not something i track closly, i would myself ask TheMuso and cjwatson 
[08:34]  * Fudge pokes cjwatson 
[08:34] <Fudge> cool tks
[08:59]  * smb needs to reboot
[08:59]  * apw has needed to reboot for two days now
[09:02] <cjwatson> Fudge: right now I don't believe GRUB has any sound support; may have been something that was hacked into GRUB Legacy by somebody and hasn't been brought forward to GRUB 2
[09:03] <cjwatson> well, that isn't quite true, it has a basic 'play' command
[09:03] <Fudge> cjwatson  thanks for that
[09:04] <Fudge> what does the basic play command do
[09:04] <cjwatson> it's just incredibly basic pitch/duration kind of stuff; there's no way you could use it for text-to-speech
[09:04] <cjwatson> and it's only using the PC speaker
[09:05] <apw> wh
[09:05] <apw> which doesn't exist on much new h/w
[09:05] <Fudge> we already use a grub beep when the menu comes up, im not sure if it would be helpful making a beep everytime u down arrow or not, that way i guess u could count the entries
[09:05] <Fudge> apw  boards still ahve speakers u can plug straight onto the boards though
[09:06] <apw> yeah i guess if you need accessibility of that sort you can tailor your purchases to ensure you have what you need
[09:06] <cjwatson> a serious GRUB TTS effort would need to start by adding a proper audio framework
[09:06] <Fudge> that would be pretty tough i imagine
[09:06] <cjwatson> yes
[09:06] <cjwatson> guess why it hasn't been done ;-)
[09:07] <Fudge> would be awesome though for accessibility
[09:07] <apw> cjwatson, as we have TTS in the kernel i wonder if we could use a kexec based scheme
[09:07] <cjwatson> I'm not going to have GRUB exec bits of the kernel, no :)
[09:07] <Fudge> u would still need a soft synth though for msot wouldnt you?
[09:07] <cjwatson> it's not unheard of to port Linux drivers into GRUB
[09:07] <apw> heh i more meant just booting a fixed kernel to do the reading
[09:07] <cjwatson> there wouldn't be a sensible way to get back
[09:08] <cjwatson> especially not in e.g. UEFI
[09:08] <apw> and using like a pygrub sort of thing to do the actual grub-like behaviours
[09:08] <Fudge> not feasable?
[09:08] <cjwatson> not worth so not worth the pain
[09:08] <apw> right essentially shim the bootloader to load an initial kernel, and let it speak and chose the real kernel
[09:08] <cjwatson> anyway I want to replace pygrub too :)
[09:08] <apw> :)
[09:08] <Fudge> i just grep menuentry and count down entries
[09:09] <apw> anyhow something people who know what they are talking about should think about :)
[09:09] <Fudge> agreed :D, thats not me
[09:09] <Fudge> loL
[09:09] <cjwatson> a minimal synth framework doesn't necessarily have to be horribly difficult, but it would need thought; I'd be surprised if nobody's looked at it, although I don't see anything plausible in trunk
[09:42] <_ruben> oh sweet .. i might get my hands on a cluster of 3 boxes with fusion-io cards .. shame lucid doesn't do trim support ho
[09:42] <_ruben> tho
[10:06] <apw> bah managed to get X to dump core
[11:54] <alexbligh> Any ideas why I can't clone the ubuntu-oneiric git tree?
[11:54] <apw> alexbligh, what happens
[11:54] <alexbligh> I get "fatal: The remote end hung up unexpectedly"
[11:54] <alexbligh> with "git clone git://kernel.ubuntu.com/ubuntu/ubuntu-oneric.git"
[11:55] <alexbligh> changing oneiric to natty works
[11:55] <alexbligh> (but I'd like oneric please)
[11:55] <alexbligh> :-)
[11:55] <apw> oneiric 
[11:55] <alexbligh> arse :-)
[11:55] <alexbligh> sorry. Normal service will be resumed (etc.).
[11:55] <apw> one-eyed-rick
[11:56] <alexbligh> Actually, whilst you are about, do you happen to know if CONFIG_XEN_BLKDEV_TAP is disabled for a reason?
[11:56] <alexbligh> I /think/ that's whats stopping PV drivers work in Xen4 (yet to check)
[11:57] <alexbligh> (+ CONFIG_XEN_BLKDEV_TAP2)
[11:57] <apw> that option doesn't show up one way or the other so must have a pre-requisite which is not on
[11:58] <apw> smb ^^
[11:58] <apw> cking, she did 30 s/r cycles with 2x glxgears
[12:01] <alexbligh> smb, well CONFIG_XEN_DOM0=y
[12:01] <alexbligh>  is on, but I think am not sure the BLKTAP stuff comes in by default unless you enable it.
[12:02] <apw> alexbligh, ok where are you even seeing that
[12:02] <apw> apw@dm$ git grep XEN_BLKDEV_TAP
[12:02] <apw> apw@dm$ 
[12:03] <alexbligh> amb@DBS:~/xen/ubuntu/git/ubuntu-natty$ git grep XEN_BLKDEV_TAP
[12:03] <alexbligh> debian.master/config/config.common.ubuntu:CONFIG_XEN_BLKDEV_TAP=y
[12:03] <alexbligh> debian.master/config/config.common.ubuntu:# CONFIG_XEN_BLKDEV_TAP2 is not set
[12:03] <alexbligh> drivers/xen/Kconfig:config XEN_BLKDEV_TAP
[12:03] <alexbligh> drivers/xen/Kconfig:config XEN_BLKDEV_TAP2
[12:03] <alexbligh> drivers/xen/Kconfig:    depends on XEN_BLKDEV_BACKEND != n && XEN_BLKDEV_TAP2 != n
[12:03] <alexbligh> drivers/xen/Kconfig:    default XEN_BLKDEV_BACKEND || XEN_BLKDEV_TAP2
[12:03] <alexbligh> drivers/xen/Makefile:obj-$(CONFIG_XEN_BLKDEV_TAP)               += blktap/
[12:03] <alexbligh> drivers/xen/Makefile:obj-$(CONFIG_XEN_BLKDEV_TAP2)              += blktap2/ blktap2-new/
[12:03] <alexbligh> drivers/xen/blktap/Makefile:obj-$(CONFIG_XEN_BLKDEV_TAP) := xenblktap.o
[12:03] <alexbligh> drivers/xen/blktap2-new/Makefile:obj-$(CONFIG_XEN_BLKDEV_TAP2) := blktap2-new.o
[12:03] <alexbligh> drivers/xen/blktap2/Makefile:obj-$(CONFIG_XEN_BLKDEV_TAP2) := blktap.o
[12:03] <alexbligh> hmmm....
[12:03] <alexbligh> perhaps that comes out of my xenlinux patches. Sigh.
[12:04] <apw> yep, not in natty or oneiric
[12:04] <apw> and if its off, i think you'd have to blame you :)
[12:05]  * alexbligh blames me
[12:13] <smb> alexbligh, AFAIK blktap was one not yet upstream
[12:13] <smb> and its not the thing that prevents pv drivers from work
[12:13] <smb> its the thing I keep complain about on xen-devel and usually be ignored
[12:16] <smb> alexbligh, name your device xvd in the cfg and put blkfront into /etc/initramfs-tools/modules (think plus the pci one) regenerate initramfs and you got the pv disk
[12:20] <alexbligh> smb, I /think/ you are talking about domU? I have the same domU booting with PV on xen3.3, but not on xen4
[12:21] <alexbligh> smb, pv NICs work on both
[12:22] <alexbligh> (it's a Centos 2.6.18 domU with the original unmodified_drivers stuff, i.e. practically the recommended Xen3.3 domU kernel, but no other domU including any Ubuntu one picks up PV disk)
[12:22] <smb> alexbligh, Yes, the problem is stupid blkfront now refuses disks that are not named xvd (or get that major) while it happily ejects the same before because you have the blkfront driver available
[12:22] <smb> Ok, its not blkfront that ejects the emulated disks but still
[12:23] <alexbligh> smb, I think you are talking about xen_emul_unplug, and the stuff that does a PCI unplug of the emulated disks in the guests?
[12:23] <smb> I do
[12:23] <alexbligh> That isn't the problem (well, it is a problem, but it's a different problem)
[12:24] <alexbligh> because 2.6.18 doesn't have the check_magic or PCI unplug stuff in at all
[12:24] <alexbligh> and xen_emul_unplug=unnecessary fixes that (or should do)
[12:24] <smb> alexbligh, What device name is in the xen config file for the domU
[12:24] <alexbligh> But that problem causes the EMULATED disks not to appear. Our problem is that the PV disks don't appear
[12:25] <alexbligh> we have tried both hda and xvda
[12:25] <smb> hda won't work for sure
[12:25] <smb> xvda has worked for me
[12:25] <alexbligh> We are using: disk = [ "tap:aio:/root/Iain2011/centos-pvd.img,hda,w" ]
[12:25] <smb> But you also need to force the blkfront driver into initrd
[12:25] <alexbligh> or disk = [ "tap:aio:/root/Iain2011/centos-pvd.img,xvda,w" ]
[12:25] <alexbligh> in domU?
[12:25] <alexbligh> (I presume)
[12:25] <smb> Yes in domU
[12:26] <smb> Placing them into /etc/iniramfs-tools/modules will not only put them into initramfs but also make sure they get loaded
[12:26] <alexbligh> I'm pretty sure it's built in (not as a module) on this version
[12:27] <alexbligh> We see the block driver initialising, but no disks appearing
[12:27] <alexbligh> What we don't see is blktapctrl running in dom0
[12:27] <smb> Ok, I was looking at the issue with an Oneiric domU
[12:27] <alexbligh> I /think/ that is meant to start even before a domU starts (i.e. when xend starts). It seems to on Xen 3.3.1
[12:28] <alexbligh> With an Oneiric domU we see no HD at all, unless we do xen_emul_unplug=unnecessary, when we see only emulated, not PV.
[12:28] <smb> alexbligh, Actually I am not sure, but there was some tap driver not yet in the kernel code (which would be part of the Oneiric dom0)
[12:29] <alexbligh> Even on 3.0.2?
[12:29] <smb> So that might be the actual problem
[12:29] <smb> What 3.0.2 are you talking about?
[12:29] <smb> Oneiric Xen version is 4.1.1
[12:29] <alexbligh> Linux xen4 3.0.0-12-server #20-Ubuntu SMP Fri Oct 7 16:36:30 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[12:29] <alexbligh> Sorry, 3.0.0
[12:30] <alexbligh> (that's the dom0 kernel)
[12:30] <smb> Right, well let me double check but I thought that exactly was something the citrix guys have been asking haow to best add support for on their own (by dkms)
[12:31] <alexbligh> "Features queued for 2.6.40:
[12:31] <alexbligh> xen-blkback backend driver to be used in dom0 to serve virtual block devices (disks) to VMs.
[12:31] <alexbligh> xen-pciback backend driver to be used in dom0 to support PCI passthru to VMs."
[12:31] <alexbligh> foolishly I therefore assumed it was in 3.0
[12:32] <smb> In order to have good block performances XAPI relies on an Open Source
[12:32] <smb> kernel module called "blktap". "blktap" is not currently upstream in the
[12:32] <smb> Linux kernel and probably won't be in the foreseeable future.
[12:32] <smb> ^ Thats from a mail I received
[12:32] <alexbligh> (sigh). So we need to get that from Citrix / Jeremy's git tree?
[12:34] <smb> I cannot really say where it would be. That mail came from Stefano so he would likely know where blktap would be obtainable
[12:34] <smb> And maybe they already have it as a dkms package
[12:35] <alexbligh> smb, thanks. We will go hunting
[12:36] <smb> There is basically two things xen-blkfront for normal file: mappings and blktap (or whowever they call it) for tap:aio. So I also misunderstood what you tried to do there
[12:36] <smb> I only checked file: mappings
[12:38] <alexbligh> so we are trying to do aio, and thus need blktap, right?
[12:39] <alexbligh> http://wiki.xensource.com/xenwiki/XAPI_on_debian  <- has some dkms stuff for Debian but only 32bit?!
[12:39] <smb> alexbligh, That would be my understanding, right
[12:45] <smb> wget http://downloads.xen.org/XCP/debian/blktap-dkms_0.1_all.deb <-- sounds like arch indep
[12:45] <smb> alexbligh, ^
[12:55] <_ruben> an arch dependent dkms package sounds rather odd .. well .. it can contain pre-compiled binaries as well .. tho usualy they are source only
[12:59] <smb> _ruben, From the name of it I am pretty sure it is not arch dependant
[13:00] <_ruben> smb: indeed, didn't mean to argue with that ;)
[13:01] <smb> Me neither. Bah who am I arguing about arguing. :-P
[13:03]  * smb begins to hate the new way of alt-tab
[13:18] <apw> smb, begins ...
[13:18] <smb> apw, I know you are already at intermediate or pro level... :)
[13:19] <apw> i am more supprised you have taken this long to hate it
[13:19] <smb> apw, Just because I did my *work* on natty for as long as I could allow myself... :-P
[13:20] <apw> heh ...
[13:23] <alexbligh> smb, a simple question: if I run the Oneiric installer under Xen4 HVM with (theoretical PV driver support), do you expect it to report that there are "no disks" becaus of the installer not modprobing blkfront, and would you expect a modprobe to fix it?
[13:25] <smb> yes and no...
[13:25] <smb> yes, it will report no disks (because emulated are unplugged)
[13:26] <alexbligh> and no, because?
[13:26] <smb> and no it will not work because we forgot to put the blkfront into the udeb package, which the installer uses
[13:27] <alexbligh> ok, so I conclude that it would be best for us to test PV on HVM using something else as domU (e.g. Centos)? :-) I think the same applies to Natty and Maverick (Lucid kernel is pre-unplug support I thnk)
[13:29] <smb> You can install it by passing xen_emul_unplug=never and then switch around later. 
[13:29] <alexbligh> oh sure, we were just running the installer as a 'good way to test it'...
[13:31] <smb> For other releases its the same with respect to blkfront. The virtual kernel package would have them builtin but there is no installer support for that I believe
[13:32] <smb> Lucid similar. That would also have ec2 kernel package which should actually have the blktap driver (which does not help much if the dom0 does not) and is based on a completely different Xen codebase to make things easier
[13:32]  * ogasawara back in 20
[13:33] <smb> Not that easy and Xen really go well along... :-P
[13:33] <alexbligh> EC2 is xenlinux HVM or paravirtualised I think.
[13:35] <smb> ec2 normally is paravirt (only cluster instance are hvm). And the dom0 pretty much centos plus xen 3.something
[13:36] <alexbligh> smb, any idea why the xen-4.1.1 hypervisor package does not appear to contain blkctrl, even though the original Xen source does? Is this debian removing it because of openssl stuff?
[13:36] <smb> alexbligh, That I have no idea about
[13:37] <alexbligh> we think that's the main problem. If we copy over a built-from-source blktapctrl daemon, do a mknod on /dev/xen/blktap0, then start the domU, it appears with block pvdrivers
[13:37] <TeTeT> in which git branch would I find the sources to linux-image-generic-pae-lts-backport-natty ?
[13:39] <tgardner> TeTeT, its in the lucid repository
[13:40] <TeTeT> tgardner: apt-get source linux-image-generic-pae-lts-backport-natty would be the best way?
[13:40] <smb> alexbligh, I could only guess that since blktap is not part of the kernel upstream it did not make sense. Maybe zul knows some background there.
[13:40] <tgardner> TeTeT, no, the source package is linux-lts-backport-natty
[13:41] <tgardner> linux-image-generic-pae-lts-backport-natty is a binary
[13:41] <TeTeT> tgardner: ok
[15:33] <apw> bjf, heads up i just pushed an update to hardy/master-next to fix CVE-2011-3209 wrt openvz
[15:33] <ubot2> apw: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3209)
[15:34] <bjf> apw, ack
[15:36] <apw> tgardner, ok i've pushed the fix for the posix-timer over master-next, and i've sent out the updated patch for 1768 out in reply to the original.
[15:38] <tgardner> apw, I just emailed my custom binary maintenance proposal.
[15:39] <apw> tgardner, ack
[15:56]  * apw wanders to the pub :)
[15:56] <smb> apw, Have one for me too
[15:56] <Daviey> apw: slacker
[15:57] <apw> Daviey, yep ... smb, yep
[17:44] <GRiD> join #ubuntu-uds
[17:44] <GRiD> sorry :)
[18:15]  * tgardner -> lunch
[18:36] <slangasek> tgardner: when you're back from lunch, would like to talk to you about bug #842560
[18:36] <ubot2> Launchpad bug 842560 in udev "bnx2 firmware missing" [Undecided,Confirmed] https://launchpad.net/bugs/842560
[18:37] <slangasek> it's possible this is a udev bug, but not in the way you suggest, so I'd like us to put our heads together to figure out what's happening here
[18:53] <tgardner> slangasek, ok. apw and I theorized about it a bit, but it seems like the 60 second delay is a dead giveaway.
[18:54] <slangasek> tgardner: the 60 second delay is because the module-loading helper is *hanging* for some reason, and udev patiently waits for 60 seconds before killing it
[18:54] <slangasek> but it only happens with this particular firmware
[18:54] <slangasek> s/module-loading/firmware-loading/
[18:54] <tgardner> slangasek, its the 2nd time the firmware is loaded. the first one seems to succeed
[18:55] <slangasek> the firmware is being loaded twice?
[18:55] <tgardner> slangasek, two physical adapters, so 2 PCI instances, etc
[18:55] <slangasek> ok
[18:55] <slangasek> I didn't see a first successful load in the logs - where do you see that?
[18:56] <tgardner> its implied because there is no failure.
[18:56] <tgardner> not real helpful, huh ?
[18:57] <slangasek> but then how do you know it's not the first load that's failing? :)
[18:57] <slangasek> oh, because the messages are about the second pci device
[18:57] <tgardner> slangasek, because eth0 always seems to work. 
[18:57]  * slangasek nods
[18:57] <tgardner> though you might have a point.
[18:58] <slangasek> well, the log shows all the messages related to eth0 first, and then the failure is bracketed by messages about eth1
[18:58] <slangasek> so I think you're right that it's the second load that's failing
[18:58] <slangasek> we should get a udev log from the initramfs to be sure
[18:58] <tgardner> that assumes that PCI probes happen in ascending order
[18:59] <slangasek> oh, I'm not assuming anything about the order, just observing that the probing appears to be happening serially, with the first one completing before the wedged firmware load
[18:59] <tgardner> I wish the reporter in https://bugs.launchpad.net/ubuntu/precise/+source/linux/+bug/842560/comments/32 had attached the whole dmesg. I think there is info missing from it.
[18:59] <ubot2> Launchpad bug 842560 in linux "bnx2 firmware missing" [High,Confirmed]
[19:00] <tgardner> slangasek, but you do agree that its likely a udev issue ?
[19:01] <slangasek> tgardner: I don't think so... I can't think of any reason why udev would be flaking out when asked to load this firmware
[19:01] <slangasek> to me it looks like things are getting stuck on the kernel side
[19:02] <slangasek> tgardner: do you have the hardware to reproduce this?  or should I talk to TRellis?
[19:02] <slangasek> I can provide some patches to the udev initramfs scripts for debugging
[19:02] <tgardner> slangasek, I don't, so yeah TRellis is your man
[19:02] <slangasek> ok
[19:41] <lamont> tgardner: bug 882751
[19:41] <ubot2> Launchpad bug 882751 in linux "kernel spams syslog with invalid src mac address, a2: 00:00:00:00:00:00" [Undecided,New] https://launchpad.net/bugs/882751
[21:18] <Trond--> Why an Ubuntu Kernel and not the official Linux Kernel?