[00:02] <maks_> uups already asleep crimsun 
[00:02] <maks_> right that was the new interface thanks :)
[00:03] <maks_> i was starting a bisect when the reboots reproducibily went random
[00:04] <maks_> was due too load order and having it on first slot ;)
=== asac_ is now known as asac
=== foka_ is now known as foka
[09:40] <TeTeT> as discussed in the roundtable, here a start for a walkthrough for the driver update cd, module package creation: https://wiki.ubuntu.com/KernelTeam/Hardy/DriverUpdateCd
[13:33] <tjaalton> my iwl4965 sometimes crashes when trying to suspend the machine (and the driver is removed). I'm using the version from lbm, so maybe I don't need the led :)
[14:49] <nxvl> hey
[14:50] <nxvl> i'm having this problem with my ricoh card reader
[14:50] <nxvl> and a lot of people seems to have it on google
[14:50] <nxvl> but there is still no solution
[14:50] <nxvl> at least no one than i have find
[14:51] <stgraber> nxvl: the "is disabled" thing ?
[14:51] <nxvl> stgraber: yep
[14:51] <stgraber> I have it too, HP Compaq 8510p
[14:51] <nxvl> [   27.567602] ricoh-mmc: Controller is now disabled.
[14:52] <mjg59> That's saying that the mmc controller is disabled, which in theory allows the SD reader to read MMC cards as well as a result
[14:52] <nxvl> well
[14:52] <mjg59> The windows sdhci driver won't read MMC cards, hence the separate controller
[14:52] <nxvl> it doesn't
[14:52] <mjg59> Yes, but it's nothing to do with tha tmessage
[14:52] <nxvl> mjg59: what else do you need?
[14:52] <mjg59> A bugfix
[14:52] <mjg59> I've no clue what causes the fact that it doesn't work (I have the same problem)
[14:53] <nxvl> oh
[14:54] <stgraber> I would love a fix too :) I currently have a separate card reader which is somewhat stupid when you have an internal card reader :)
[14:58] <nxvl> yep
[14:58] <nxvl> i'm going for a trip i don't have a camera cable and not a lot of space in the memory card
[14:58] <nxvl> so i'm kind of in problems
[14:59] <nxvl> i have found this patch
[14:59] <nxvl> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=882c49164d72c45f37d7fa1bb3de7c31cf1a5fab#patch1
[15:00] <nxvl> and some commendts saying it solves the problem
[15:00] <nxvl> BUT
[15:00] <nxvl> i don't know how to compile only the module and not the whole kernel
[15:00] <nxvl> so i haven't tried it yet
[15:53] <laga> amitk: are you guys still interested in hearing about aufs (and how it's used in ubuntu)?
[16:06] <BenC> laga: Mainly we are interested in how we can use it for livecd
[16:06] <BenC> laga: We know it works, we just need to enable it for the livecd build
[16:06] <BenC> so it can start to be tested more widely in that context
[16:07] <laga> oh, that's simple.
[16:08] <laga> "Ubuntu 8.04 allows the user to boot the standard installation disk (the
[16:08] <laga> live disk) with aufs instead of unionfs, by using the union=aufs option."
[16:08] <BenC> really?!
[16:09]  * BenC wishes he knew that
[16:09] <laga> that's what julian andres klode, the aufs guy for debian, said on the aufs-users ML.
[16:12] <cking> That's news to me.
[16:21] <amitk> laga: that is good news indeed if it works. 
[16:22] <amitk> laga: how actively is it being developed
[16:22] <amitk> ?
[16:24] <laga> amitk: aufs or the initramfs patch?
[16:24] <amitk> laga: aufs
[16:24] <laga> amitk: new "monday release" every, umm, monday. those are basically stable CVS snapshots.
[16:24] <amitk> laga: the aufs page lists lots of patches needed to apply to get it to work properly
[16:25] <amitk> any plans to upstream aufs?
[16:25] <laga> the maintainer is usually friendly and responsive..
[16:25] <laga> amitk: some of those patches are applied to the ubuntu kernel already.
[16:25] <laga> amitk: i dont think upstream likes stacking file systems like aufs or unionfs. but you better ask the maintainer about that.
[16:26] <BenC> not-upstream == more work for us
[16:26] <laga> unionfs isnt upstream either :)
[16:26] <BenC> if upstream has a better way to do livecd than a stacking filesystem, we'd like to hear about it
[16:27] <BenC> laga: yeah, but we want to follow something that has a chance
[16:28] <amitk> laga: we aren't anti-aufs :) We just don't want to swap one set of bugs for another set of bugs without any long term benefit
[16:28] <laga> :)
[16:28] <laga> aufs works better for me with NFS. that's all i can say. :)
[16:29] <laga> upstream prefers a completely different upstream to stacking file systems, but i haven't followed the discussion closely
[16:29] <laga> um.
[16:29] <laga> a completely different approach.
[16:31] <amitk> ok
[16:32] <laga> it'd be great if aufs was used for the live disk. i use for diskless clients in mythbuntu and it works very well there.
[16:34] <amitk> we are planning to do a test livecd with aufs
[16:38] <laga> lots of live disks use aufs, i'm sure you won't be disappointed
[16:38]  * laga afk
[18:03] <maks_> crimsun: do you have link for useful output on an alsa bug report?
[21:16] <crimsun> maks_: kernel- or userspace?
[21:16] <maks_> dealing mostly kernel side
[21:16] <crimsun> maks_: ok, driver (codec) or core?
[21:17] <maks_> haha, ok hmm most are driver
[21:17] <maks_> (generic question so i'd be better guide for the next filing)
[21:17] <crimsun> maks_: ok, then the appropriate codec info is useful.  /proc/asound/card*/*codec*
[21:18] <crimsun> maks_: there's a script (http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh) to gather the more useful info.
[21:19] <maks_> thanks crimsun 
[21:20] <crimsun> np
[21:35] <sectech> I was wondering if someone could help with a bug I am triaging (I am a member of bugsquad)... The bug on launchpad is bug #231986...The summary is that the reporter has a soundcard in his laptop with the ALC861VD chipset and it isn't working... I have made our standard information request for hardware detection and I am finding the device isn't even showing up in lspci -vvv... Can someone help me out with this?
[21:40] <maks_> cat /proc/asound/cards, lsmod
[21:43] <maks_> sectech: HD Audio Controller [8086:284b]
[21:44] <maks_> it is shown in lspci
[21:45] <sectech> Ahh... It is now... The previous lspci didn't show it
[21:46] <sectech> I can only go by what the reporter submits...
[21:46] <maks_> 22:16 <crimsun> maks_: there's a script 
[21:46] <maks_>                 (http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh) to 
[21:46] <maks_>                 gather the more useful info.
[21:47] <maks_> don't see that particular laptop in alsa changelog
[21:47] <maks_> guess it needs it's own quirks
[21:47] <maks_> snd-hda is the new ata piix :)
[21:47] <sectech> maks_,  Okay, I'll ask the reporter to get that file, run and submit the result...
[21:47] <johanbr> sectech: see also http://ubuntuforums.org/archive/index.php/t-636194.html
[21:48] <sectech> Okay
[21:49] <sectech> johanbr,  I saw on one of the forums they that they requested that the user install the backports package for his kernel...  So I made the same request, I ended up getting a reply stating it now makes a sputtering noise I guess
[21:50] <sectech> Yeah this doesn't seem new
[21:56] <crimsun> sectech: the two most useful pieces of info are 1) lspci -nv|grep -A1 0403 ; 2) the contents of /proc/asound/card*/*codec*
[21:56] <crimsun> sectech: for PCI audio devices, the SSID is much more useful (hence grep -A1).
[21:57] <crimsun> sectech: (the script takes care of grabbing that info)
[21:58] <sectech> crimsun,  Thank you... I documented that for myself for the next audio problem I run into... 
[21:58] <sectech> It's difficult sometimes when you don't know 100% what to ask for, this helps a lot
[21:58] <crimsun> sectech: np
[21:59] <crimsun> the script is (or should be) mentioned on wiki/DebuggingSoundProblems
[22:01] <sectech> Hmm... okay.... 
[22:01] <crimsun> I think bdmurray, ogasawara__, and I talked about it last UDS, so it should be there.
[22:05] <sectech> yes it's there... I guess I missed that
[22:05] <sectech> thanks crimsun 
[22:07] <crimsun> np