[08:27] <AnAnt> Hello, will the opensource broadcomm wireless firmware (https://lists.berlios.de/pipermail/bcm43xx-dev/2009-January/008466.html) be used in next release of Ubuntu ?
[08:33] <AnAnt> http://www.ing.unibs.it/openfwwf/
[10:37] <JanC> AnAnt: they say that their open source firmware is not complete?
[10:41] <Kano> b43?
[10:41] <JanC> Kano: an open source firmware for b43
[10:43] <Kano> i know that this exists,but did anybody try it
[10:46] <JanC> I'm sure the authors test it ;) but they also say that it doesn't work yet with encrypted connections and some other wifi protocol features
[10:48] <JanC> well, it seems like they might have fixed the encryption support since that mail
[10:50] <Kano> would be good to include it then
[10:55] <AnAnt> JanC: I don't think that HW encryption got fixed
[10:55] <AnAnt> neither the QoS feature
[10:55] <AnAnt> I followed the thread in their archives
[10:56] <JanC> AnAnt: ah, they still only support SW encryption then?
[10:56] <JanC> which is probably dead slow  ツ
[10:56] <AnAnt> ok
[10:56] <JanC> (I didn't test it, that was just an assumption)
[10:57] <AnAnt> so isn't anyone from Ubuntu following up with this firmware ?
[11:01] <JanC> hm, maybe SW crypto is "good enough" for station mode (as opposed to e.g. AP mode where it would have to cater for multiple connections) ?
[11:03] <JanC> seems like the rt2500* drivers don't implement HW crypto either
[13:41] <rtg> apw: you mentioned you had some scripts you were working on for the vanilla kernel build.
[13:52] <apw> yeah, i am testing them right now.  think i have the nameing sorted.  my plan is to complete a couple of test builds, then write up how i think we should be using them and email that out to the kernel-list
[13:52] <apw> should happen today
[14:18] <Kano> hi rtg , i saw you added the rt firmware, did you get my mail with some more missing firmware? the 2 for dvb devices are even mentioned in launchpad
[14:19] <rtg> Kano: working on it
[14:19] <Kano> you added d
[14:19] <Kano> a-c still missing
[14:19] <rtg> Kan RT works, right?
[14:19] <Kano> no complains
[14:20] <rtg> I'll get the rest of the firmware soon
[14:20] <Kano> only usb tested so far,but i guess your kernel works for pci too
[15:02] <Kano> what do you think of adding the new free b43 firmware?
[15:03] <Kano> would be good when you dont need the fwcutter to go online
[18:43] <CarlFK> smb_tp: you mind helping me get a Firewire ExpressCard  working?  (on the x64 box, any kernel.  tired ibex 32, nothing.  jaunty x64, pciehp module doesn't  exist 
[18:46] <smb_tp> CarlFK, I can try. You got a bit more info? What exactly would you need? 
[18:47] <CarlFK> smb_tp: lets start with: why isn't there a pciehp module for x64 jaunty?  there is for 32 jaunty 
[18:48] <CarlFK> http://packages.ubuntu.com/search?suite=jaunty&arch=any&mode=filename&searchon=contents&keywords=pciehp
[18:48] <CarlFK> lib/modules/2.6.27-1-386/kernel/drivers/pci/hotplug/pciehp.ko                   	 	linux-image-2.6.27-1-386 [not amd64] 	         
[18:48] <smb_tp> CarlFK, Would have to have a peek at the source. Either its just a glitch in the config or some dependency thing
[18:50] <CarlFK> ok - wanted to make sure there wasn't some alternative i should be trying 
[18:51] <smb_tp> Hm, build when CONFIG_HOTPLUG_PCI_PCIE is set. Which it is on both
[18:51] <CarlFK> carl@dv67:~$ sudo modprobe pciehp
[18:51] <CarlFK> FATAL: Module pciehp not found.
[18:51] <smb_tp> actually it might not be a module 
[18:52] <CarlFK> doh
[18:52] <CarlFK> carl@dv67:~$ dmesg|grep pciehp
[18:52] <CarlFK> [    1.247944] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[18:52] <CarlFK> ok, so on to the next problem: 
[18:53] <CarlFK> the card has 2 firewire and 1 usb.
[18:53] <CarlFK> usb works (the lack of module was making me think magic)
[18:54] <CarlFK> but the firewire doesn't (at least not the way the on board fw does)
[18:54] <CarlFK> as in, I plug in a fw to onboard, hotplug happens, device is live
[18:55] <CarlFK> plug into card's fw, nothign.  no dmesg, no change in lscpi.. 
[18:55] <smb_tp> Hm, that means? Is any driver claiming /driving it=
[18:55] <smb_tp> ?
[18:56] <CarlFK> not that I can tell
[18:59] <smb_tp> One thing to search for would be the pci id 
[18:59] <CarlFK> lshw doesn't change when I plug in the card
[18:59] <CarlFK> pci id coming up.. 
[19:03] <CarlFK> I have it around here somewhere.  
[19:03] <CarlFK> any idea how to query the EC buss?  (express card)
[19:06] <smb_tp> Doh, all my hw is too old. Might it get added to the pci subsystem and just show up with lspci?
[19:06] <CarlFK> nope
[19:06] <smb_tp> lspcmcia
[19:07] <CarlFK> sudo lspcmcia - nothing.
[19:08] <CarlFK> sudo pccardctl info - nothing. same for status, ident, config
[19:08] <smb_tp> Anything in /sys/bus/pci_express/devices ?
[19:10] <CarlFK> yes.. digging
[19:14] <CarlFK> http://dpaste.com/111904/  best I have so far...
[19:15] <CarlFK> I put the card into a mac, and was able to get a pciid, which I posted somewhere,,,
[19:24] <CarlFK>  0a:00.0 FireWire (IEEE 1394) [0c00]: JMicron Technologies, Inc. Device [197b:2380]
[19:26] <CarlFK> and from the kino/dvgrab list: > The card  itself should be no different than the pcie jmicron cards I've got, which work  fine 
[19:29] <smb_tp> just grep'ing the tree. nothing for 2380 in the upstream part. 
[19:30] <smb_tp> neither in ubuntu specific modules
[19:31] <smb_tp> do the other cards you got show up on lspci or any other place?
[19:31] <CarlFK> I only have that one card
[19:32] <CarlFK> tonight I can get a 2nd card.  its a ...evode? card
[19:34] <smb_tp> Oh, nm. That was from a mailing list post. 
[19:34] <CarlFK> right
[19:35] <smb_tp> you said it has a usb part which is working. does that device show up?
[19:35] <CarlFK> yes - under lsusb
[19:39] <smb_tp> Hm, yeah. Make sense. One thing that might show a bit more would be to tune up the udev logging and listen to the events with udevadm monitor while plugging...
[19:45] <CarlFK> smb_tp:  ever see the Far Side comic: "Bad dog Ginger.  Don't do that again Ginger.  No, no Ginger."  What the dog hears: "bla bla Ginger.  bla bla bal bla Ginger.  bla bla Ginger."
[19:45] <CarlFK> that would be you me :)
[19:45] <CarlFK> so what's this tune up the udev logging you speak of?
[19:46] <smb_tp> CarlFK, Heh, no, not yet. :)
[19:47] <smb_tp> Tune up is probably not best expressed. Better increase the log level "udevadm control --log-priority=debug"
[19:48] <smb_tp> Then running "udevadm monitor --kernel --environmen --udev"
[19:49] <smb_tp> shows the events as they come in
[19:49] <CarlFK> carl@dv67:~$ sudo udevadm monitor --kernel --environmen --udev
[19:49] <CarlFK> monitor will print the received events for: UDEV the event which udev sends out after rule processing; UEVENT the kernel uevent
[19:49] <CarlFK> plug, unplug.. nothing 
[19:50] <CarlFK> plugged a usb stick into the card's usb got stuff
[19:51] <CarlFK> http://dpaste.com/111924/
[19:52] <smb_tp> Grr... great. Seems I have no idea how this should work. :(
[19:55] <JackWinter> i have a kubuntu 8.10 running in a vbox.  thought it would be a good idea to install the virtual kernel, but apt installed the server version.  are they the same or is something messed up ?
[19:56] <rtg> JackWinter: they are the same. the virtual package is generated using binaries from the server flavour
[19:57] <JackWinter> rtg: thanks
[19:57] <JackWinter> are there any news on a rt kernel for 8.10 ?
[19:58] <rtg> JackWinter: I'm not keeping up with whats going there, perhaps smb_tp can answer.
[19:58] <JackWinter> i'll hang around a while
[19:59] <smb_tp> rtg, AFAIK if there is one it is community supported as the -ports
[20:16] <mnem0> rtg: did these intel fixes make it into the new kernel? --> https://lists.ubuntu.com/archives/kernel-team/2009-January/004178.html
[20:18] <rtg> mnem0: those fixes are actually in the source for -5.12. I'm just not sure why they didn't show up in the diff.
[20:19] <mnem0> ok great... im being hit by a really bad xorg crash bug which is fixed by these patches
[20:20] <rtg> mnem0: well, I'm about to get the other ABI dependent packages uploaded so you should have an update tomorrow or the next day
[20:20] <mnem0> sweet
[20:20] <mnem0> thanks
[20:24] <smb_tp> CarlFK, I talked over that on another channel. That firewire card should show up with lspci. Is that the only slot you got? Or have you tried to have the card in on boot to avoid hotplug?
[20:25] <CarlFK> only slot, have not tried on boot.  will reboot now
[20:26] <tjaalton> rtg: hum, I fetched the source for 5.13 and I can't see them in there
[20:26] <rtg> hmm
[20:28] <tjaalton> at least the one touching include/drm/i915_drm.h
[20:28] <tjaalton> c0399d5596fb reverted it
[20:29] <rtg> tjaalton: do a git log on that file. I think something ugly happened.
[20:29] <rtg> 'UBUNTU: Enabled CONFIG_PID_NS=y for i386/amd64' wrecks it. wtf?
[20:29] <tjaalton> yes
[20:30] <tjaalton> basically what was said on the email ;)
[20:30] <rtg> tjaalton: I think I managed to do that one all by myself. drat.
[20:31] <rtg> I wonder if I messed up a rebase.
[20:41] <CarlFK> smb_tp: having hte card in when I power up the box makes a new FW bus show up
[20:42] <CarlFK> plugging in fw device now
[20:42] <rtg> CarlFK: so it sounds like a hotplug problem.
[20:46] <CarlFK> fw device is recognized.  yay.  now I can test to make sure I can capture and mix 2 fw cams on one laptop 
[21:36] <tjaalton> rtg: thanks for fixing it, tomorrow will be a good day for -intel gfx ;)
[21:38] <rtg> tjaalton: hope I got it right this time.
[21:43] <tjaalton> rtg: at least git looks good
[21:45] <tjaalton> and diff too
[23:05] <Keybuk> time with intrepid modprobe on amd64 to do 10,000 nothings:  3m13.6s
[23:06] <Keybuk> anyone care to guess how long with new modprobe? :)
[23:22] <dtchen> 3m13.0s?
[23:32] <Keybuk> no ;-)
[23:33] <Keybuk> lower
[23:33] <laga> 3m12.9s?
[23:33] <Keybuk> lower
[23:35] <laga> 3m12.8s?
[23:35] <Keybuk> lower
[23:36] <Keybuk> (this could take a while <g>)
[23:36] <laga> yeah
[23:36] <laga> about to go to bed, so just tell me ;)
[23:36] <Keybuk> 16.4s
[23:40] <laga> sweet!
[23:44] <johanbr> Keybuk: how many nothings does it do at bootup?
[23:53] <Keybuk> johanbr: modprobe nothing is a good way to measure the overhead of modprobe
[23:53] <Keybuk> ie. how much time it takes to iterate through its indexes
[23:54] <Keybuk> modprobe has always been more ridiculously more expensive than insmod
[23:54] <johanbr> I wasn't trying to be sarcastic, or anything. Just wondering how much this would save in a real situation.
[23:54] <Keybuk> so this new version plus patches seems to make it rather better
[23:54] <Keybuk> seems to be around 2-3s
[23:54] <Keybuk> of boot time
[23:54] <johanbr> nice :)