[08:00] <ppisati> morning *
[08:53]  * smb drags himself in...
[08:53] <smb> morning .+
[09:08]  * smb hopes the second cup of coffee does help more than the first one...
[10:21]  * apw looks about bleariliy
[10:22] <smb> apw, Feel any better than Friday?
[10:22] <apw> yep in one piece today
[10:25] <brendand> apw - were there any significant changes to wireless in this -proposed kernel?
[10:25] <brendand> for oneiric
[10:25] <smb> brendand, there is a changelog for that... ;)
[10:26] <apw> brendand, i would be supprised if there was any big changes at all
[10:27] <apw> brendand, i guess it is a bigger question what is your new problem
[10:28] <brendand> apw - both of the laptops we're testing that have a 'BCM4312 802.11b/g LP-PHY', the wireless card is acting up
[10:28] <apw> are they using wl ?
[10:30] <brendand> apw - lspci -vv
[10:30] <brendand> http://paste.ubuntu.com/760260/
[10:30] <apw> so what is the symptom ?
[10:33] <apw> brendand, so does the machine have wl binary direvers installed ?
[10:34] <brendand> apw - ok. i think it's likely we need to account for the case where a system has to have the binary drivers installed
[10:34] <brendand> apw - i'm guessing this is one
[10:35] <apw> brendand, so we don't know the machine worked in the current configuration on the old kernel?
[10:36] <brendand> apw - oh, it's certified so it worked. it seems that you're saying this card requires for binary drivers to be installed though? that would have been done during certification but not necessarily during the automated run
[10:37] <brendand> apw - actually, i'm quite sure it wouldn't have been done during the automated run since we don't have anything in our install scripts to do that
[10:37] <apw> brendand, well actually what i though you were telling me was that it worked in this test rig before this -proposed kernel and does not with only the kernle changed
[10:37] <brendand> apw - that's what i was thinking until you mentioned about the binary drivers
[10:37] <apw> brendand, i was asking about the wl driver as i would expect wl installed on that card, but some broadcom stuff does work without
[10:37] <apw> brendand, so its a question not a statement from my point of view
[10:38] <brendand> apw - ok. so the wl driver is not installed for the automated test run, but it was when the system was certified
[10:38] <apw> brendand, ahh then that may well make sense then
[10:42] <brendand> apw - i'll get the lab engineer to rerun the tests with the wl driver installed. it should probably work then
[10:43] <apw> sounds good
[11:13] <ledzgio> hi all
[11:19] <apw> hi
[11:20] <ledzgio> anyone can help me with a net card atheros AR8151 on ubuntu 11.10?
[11:27] <apw> whats the issue?
[11:29] <ledzgio> yes
[11:29] <ledzgio> this card gets disconnected when I download with torrent for example at high speed
[11:30] <ledzgio> and I have to rmmod module (that is atl1c) and modprobe it again
[11:30] <ledzgio> i have kernel 3.0.14
[11:30] <ledzgio> with ubuntu 11.10
[11:30] <ledzgio> i have googled a lot
[11:30] <ledzgio> but no luck
[11:30] <ledzgio> toughts?
[11:31] <apw> i've cirtainly not heard of specific issues with atl1c recently, other than issues i had on natty with it failing to detect carrier at all
[11:32] <apw> since then i'd not had issues with the atl1c i have.  that said i primarily use that machine on wireless
[11:32] <ledzgio> I cannot understand because if I surf on internet it works normally
[11:32] <ledzgio> when I donwload with deluge at high speed it gets disconnected
[11:32] <ledzgio> mine is ethernet
[11:32] <ledzgio> I dont have wireless on my desktop
[11:32] <apw> that isn't entirly unexpected, high load is likely to trigger any latent issues
[11:32] <ledzgio> and ythe wireless module is disabled by default in blacklist
[11:33] <apw> indeed, i was saying i don't use the ethernet on that machine much and not under high load
[11:33] <ledzgio> ok..may I try some workaround?
[11:33] <ledzgio> it happens even if I reduce the speed of deluge
[11:34] <ledzgio> after a while it disconnects 
[11:34] <ledzgio> i can send you the dmesg log of the error
[11:34] <apw> well it would make more sense to file a bug with the information
[11:35] <apw> as for debugging it, you could try running a later kernel, that may be fixed
[11:35]  * apw checks if cw has ethernet too
[11:35] <ledzgio> I have tried the 3.0.14
[11:35] <ledzgio> how can I try an experimental kernel?
[11:35] <apw> yeah i am more thinking a 3.2 based kernel
[11:35] <ledzgio> how can i try a 3.2 kernel?
[11:36] <ledzgio> should I compile it or just add some ppa?
[11:36] <apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
[11:36] <apw> those are just for testing, but if it is fixed later we have more hope of finding the fix
[11:37] <ledzgio> ok so just download the deb files and install them with apk?
[11:37] <apw> with dpkg
[11:38] <ledzgio> yes sorry dpkg
[11:38] <ledzgio> ok
[11:38] <ledzgio> I'll give it a try
[11:38] <apw> i'd suggest a 3.2-rc4 for example
[11:38] <apw> as if its not fixed there, its not fixed upstream
[11:39] <ledzgio> ok..is there a way to check some changelog to verify that 3.2 kernel has some change on my card?
[11:41] <apw> the upstream git repository has every commit made, and we are talking from v3.0 -> v3.2-rc4
[11:41] <ledzgio> url?
[11:43] <apw> there doesn't seem to be much if i am honest so your chances are low
[11:44] <ledzgio> ok...I may think to buy a new net card
[11:44] <apw> lucky you, mine is builtin
[11:45] <ledzgio> mine too, I have never had luck with builtin cards
[11:45] <ledzgio> :)
[11:47] <ledzgio> thank you anyway dude
[11:47] <apw> good luck
[11:48] <ledzgio> sorry last question
[11:48] <ledzgio> the most supported lan cards are those with realtech chipset?
[11:49] <ledzgio> cause if I have to buy a new one...I want to buy one well supported
[11:49] <apw> i think a better answer is _older_ cards are best supported, i have had good luck with older RTL lan devices, and with intel cards
[11:50] <apw> i have a BCM in my dell box, and that works ok on ethernet
[11:50]  * apw notes that all the worst wifi stuff is made by the people who make some of the least problematic ethernet cards, how odd
[11:51] <ledzgio> ok thank you
[11:55] <apw> Sarvatt, ok in theory at least on the incident of lp losing its mind we should just move the upload files aside for manual handling
[14:41] <ogasawara> apw: just curious how you went about doing your test builds for armhf?
[14:42] <apw> ogasawara, heh you don't want to know ... 
[14:42] <ogasawara> apw: I'm assuming it's a bit of a hack?
[14:42] <apw> ogasawara, i symlinked the armel compiler crosscompiler binaries to the armhf binaries in one of our chroots
[14:43] <ogra_> you can use an armhf chroot inside an armel setup
[14:43] <apw> ogasawara, and then cross compiled it there
[14:43] <apw> ogra_, yeah, but you can't make one :)
[14:43] <ogra_> or use the hf cross toolchain
[14:43] <ogra_> apw, thats what we have ubuntu-core for ;)
[14:43] <ogra_> it is one :)
[14:44] <apw> ogra_, so are there armhf cross compilers now ?  in the arhive?
[14:44] <ogra_> ask hrw, i think there is since oneiric
[14:45] <apw> ogra_, ta
[14:45] <apw> ogasawara, before i pollute you with my shit i'll figure out if there are official builds
[14:45] <ogasawara> apw: ack
[14:46] <apw> ogasawara, but in principle if it works for armel, and you do the same thing to hf as el it should be ok
[14:47] <ogra_> yeah, especially on the kernel level the naming is plain for the package name
[14:47] <ogra_> we could even just cp *armel.deb to *armhf.deb if the archive would allow that
[14:47] <apw> tgardner, i see there are official armhf cross compilers for precise, could we get those installed in the i386 chroot
[14:48] <apw> ogra_, it is annoying that we can't do that at times given the cost of makeing it
[14:48] <tgardner> apw, yeah, I'll work on  that today
[14:48] <apw> tgthanks
[14:48] <apw> tgardner, ^^
[14:48] <ogra_> apw, agreed, though in the end armel will be gone anyway
[14:48] <ogra_> its only a temporary thing 
[14:48] <apw> ogra_, "temporary" as in supported for 5 years |
[14:48] <apw> ?
[14:49] <ogra_> apw, heh, probably 
[14:49] <ogra_> i hope not though ... hf looks pretty good already 
[14:49] <apw> ogra_, do you think armel may go for precise?
[14:49] <ogra_> if until feature freeze no disasters show up hf will be the 5 yearer
[14:50] <ogra_> it wont go
[14:50] <ogra_> but it wont be the supported arch
[14:50] <ppisati> ah no?
[14:50] <apw> so we pay the pain, which is no help really
[14:50] <ogra_> we'll decide at FF based on how hf looks like
[14:50] <ogra_> we all do, yes
[14:50] <ppisati> when is feature freeze?
[14:51] <ogra_> initially hf was expected to be brought up by linaro before oneiric is done
[14:51] <ogra_> ppisati, iirc some time in feb
[14:51] <ogra_> we currently all pay for the delay 
[14:51] <ogasawara> ppisati: feb 16
[14:51] <ppisati> ok
[14:53]  * apw idly wonders what the heck software centre spends all its time doing when updating it sw catalogue
[14:54] <ogra_> running apt-update-xapian-index i bet 
[14:57] <apw> well it s
[14:57] <apw> should be doing it quicker
[14:58]  * ogra_ always has fun with it on his SD card driven machines :)
[14:58] <ogra_> can easily steal you 1h of your day :)
[15:01] <apw> man that sucks
[15:19] <infinity> apw: Can I pick your brain?
[15:23] <smb> sounds somewhat cruel...
[15:38]  * ogasawara back in 20
[15:45] <apw> infinity, yo go ahead ...
[15:45]  * apw notes that OSDs appear on his right monitor regardless of whether that is connected to the display ... sigh
[15:45] <infinity> apw: Hey.  So.  Trying to think about future-proofing lp-buildd for when we upgrade the buildds to precise.
[15:46] <infinity> apw: And we almost certainly want to use the uname26 personality, since they need to be building sources all the way back to hardy that we won't want to fix.
[15:46] <infinity> apw: But, in local testing, linux32 and uname26 seem to be mutually exclusive.
[15:46] <infinity> apw: Is there a sane reason for that, or is it just because of the way they're setting the personality mask (ie: could it be rewritten to set both?)
[15:47] <infinity> apw: I know nothing about personalities, and haven't looked much.  Thought I'd ask someone who I suspected might know.
[15:47] <apw> infinity, i don't know off the top of my head, i have not really looked at the uname26 one.  i suspect it must be possible to make both active somehow
[15:48] <infinity> http://mirror.linux.org.au/linux/kernel/people/ak/uname26/
[15:48] <infinity> ^-- dirt simple.
[15:51] <apw> infinity, well assuming 32bit comes from the personality bit limiting address space, they appear to be independant
[15:52] <infinity> apw: So it might just be that linux32 is rewriting the entire mask and blatting uname26, or some such?
[15:52] <apw> where do i find the source for linux32
[15:52] <infinity> (Though I couldn't mix/match them regardles of the order I called them in)
[15:52] <infinity> apw: linux32 is from util-linux.
[15:52] <ohsix> doesn't it just change the personality the invoked program runs with
[15:53] <infinity> ohsix: Yes.
[15:53] <apw> infinity, so i suspect its because both just change the personality
[15:53] <infinity> apw: Rather than masking it?
[15:54] <infinity> apw: ie: they're overwriting each other's hard work?
[15:54] <apw> infinity, ok in that sample uname26.c try changing the PER_LINUX to PER_LINUX32
[15:54] <apw> and see if that on its own the does both
[15:55] <infinity> adconrad@cthulhu:~/uname26$ ./uname26 uname -a
[15:55] <infinity> Linux cthulhu 2.6.40-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 i686 i686 i386 GNU/Linux
[15:55] <infinity> Lookie there!
[15:55] <infinity> apw: Snazzy.
[15:55] <apw> infinity, so yeah they are overwriting each other
[15:56] <infinity> Kay.  Well, I don't necesarily even have to daisy-chain them for the buildd case.  I can just use this dead-simple uname26-32 deal and package it up.
[15:56] <apw> so i presume we can inject our own version of linux32 when building against maverick and older
[15:56] <infinity> But fixing linux32 to not override uname26 would be nice.
[15:56] <apw> infinity, yeah i guess it'd have to look up the curent one and or in its stuff
[15:56] <infinity> Or we could patch linux32 to take a -2 switch.
[15:57] <infinity> apw: Anyhow, I just wanted to make sure it was possible, which you just proved.
[15:57] <infinity> apw: I'm the util-linux maintainer, I can hack up linux32 to have more options.  Probably the sane way.
[15:57] <apw> infinity, and that does sound like something we are going to need for what maverick and older i guess
[15:57] <infinity> apw: Yeah, I'm going to land this all in lp-buildd and precise's util-linux sometime this week, so we don't forget and panic later.
[15:58] <apw> yeah a good plan indeed
[15:59] <tgardner> apw, armhf Precise chroot on gomeisa. still working on gcc-arm-linux-gnueabihf; deps are broken.
[16:00] <apw> tgardner, oh as in a qemu emulator one is working ?
[16:00] <tgardner> apw, seems to be
[16:00] <apw> tgardner, most unexpected
[16:00] <tgardner> apw, dunno why not. armel has been working for a bit
[16:01] <apw> tgardner, and it should be identicle, so clearly there is no hope of it working
[16:01] <infinity> Oh, there's an armhf chroot on scheat now too, if you need a porter box.
[16:01] <infinity> Except that lamont hasn't install rapt...
[16:01] <infinity> So, no apt-get fun.
[16:01] <infinity> I'll chase that up. :P
[16:02] <lamont> meh
[16:02] <lamont> I'll do that once I hit town
[16:16] <apw> jibel, ok i think there is a significant portion of needing lots of CPU up the guest for this problem, i remained unable to reproduce it, moved to a much bigger test box, and couldn't not reproduce it making it hard to install a test VM
[16:16] <apw> jibel, anyhow, making progress slowly now
[16:16] <tgardner> ogra_, whats the story on the armhf cross tools? it looks like it was uploaded 8 weeks ago and FTBS'd. https://launchpad.net/ubuntu/+source/gcc-4.6-armhf-cross - what are you using ?
[16:17] <jibel> apw, I can give you access to the box if you need
[16:17] <apw> jibel, now i've switched hosts i seem to have a good reproduce by using a VM image i copied over from the slow box, and with your copy scrip
[16:20] <ogra_> tgardner, i always build natively, thats why i pointed for questions to hrw
[16:21] <tgardner> ogra_, who is hrw ?
[16:21] <ogra_> marcin juskiewicz
[16:21] <infinity> tgardner: I guarantee that cross toolchain will be vaguely wrong even if it does build.
[16:21] <infinity> tgardner: I'll have to have a poke at it when I find some free time from doing the native stuff.
[16:21] <tgardner> infinity, we mostly use it for build testing.
[16:22] <infinity> (Though vaguely wrong might not matter for kernels, I guess)
[16:22] <infinity> The tools it generates won't run, but the kernel will.
[16:22] <apw> tgardner, i found that symlinking the binaries for the armel one to armhf's abi name worked, see the precise-i386 chroot on tangerine, /usr/bin
[16:22] <tgardner> apw, the king of ugly hacks :)
[16:22] <apw> at least let me fake builds, not sure you'd want to use the result, but at least i could check the packaging
[16:23] <tgardner> apw, well, now you've got native armhf, so go slowly...
[16:23] <apw> for anything other than the kernel it'd not actually be armhf of course :)
[16:23] <apw> tgardner, yeah i'll punt a build at that chroot and see how long it takes
[16:27] <apw> tgardner, fun vv
[16:27] <apw> util/hist.c: In function 'hists__fprintf':
[16:27] <apw> util/hist.c:1223:1: internal compiler error: Segmentation fault
[16:27] <tgardner> apw, gotta love that
[16:27] <apw> (building the tools, not that i care about those one iota)
[16:28] <bjf> tgardner: which version of arm do we support for the buildds ?
[16:28] <apw> bjf, do you mean which h/w are used as buildds?
[16:28] <tgardner> bjf, imx51 I think
[16:28] <bjf> tgardner: which ubuntu series ? lucid ?
[16:29] <tgardner> bjf, lamont is the ultimate source
[16:29] <apw> bjf, if so that is fsl-imx51 running the lucid/fsl-imx51, and pandas running various releases from natty up i believe running ti-omap4
[16:29] <apw> infinity, we are running a mess of versions on the pandas arn't we
[16:30] <brendand> tgardner - just got your note about the wireless_scanning test. just to let you know, this isn't a new one, we've been using the same test in certification for a while
[16:31] <brendand> tgardner - i mixed up my tools. it's using iwconfig to find the interface name and iwlist to scan
[16:31] <brendand> tgardner - should we not be using that?
[16:33] <tgardner> brendand, iwconfig/iwlist are about to be deprecated. I think Precise is likely the last release. kernels subsequent to 3.2 will likely _not_ wotk with iwconfig/iwlist since the ioctl interface is getting deprecated.
[16:35] <brendand> tgardner - probably from our point of view it's best to use NetworkManager, isn't it (i assume NetworkManager will use whatever is correct at the back end)?
[16:35] <infinity> apw: I'm not sure.  You'd have to ask lamont.
[16:36] <tgardner> brendand, NM uses the same interfaces as iw, e.g., netlink socket AFAIK
[16:37] <brendand> tgardner - we'll look into updating it for this release. i'll file a bug in checkbox for it. for now the older releases are using iwconfig/iwlist though
[16:38] <tgardner> brendand, tahts fine.
[16:48] <brendand> tgardner - now that i've got your attention, i was hoping to get your input on one test that i've written, which monitors the state of the connection over a period of time (i think we agreed 5 minutes at UDS)
[16:48] <tgardner> brendand, OK
[16:49] <brendand> tgardner - what sort of bad behaviour do you usually see when there are regressions of this kind? does the connection actually go down?
[16:50] <tgardner> brendand, either that, or the connection rate drops to 1Mbit or slower
[16:50] <brendand> tgardner - and does it usually only happen under a high load?
[16:50] <tgardner> brendand, high loads or noise on the channel
[16:50] <tgardner> which is hard for you to reproduce.
[16:51] <tgardner> I would just test a high load and set a floor for the expected throughput.
[16:51] <brendand> tgardner - ok
[16:54] <tgardner> brendand, remember that each phy setting (b,g,n) have different throughput expectations.
[16:56] <brendand> tgardner - any tips on tools to measure throughput?
[16:57] <tgardner> brendand, I use iperf
[16:58] <vanhoof> brendand: had the same q last week
[16:59] <vanhoof> brendand: ended up with" iperf --client 172.31.1.1 --time 300 --interval 30
[16:59] <vanhoof> --format M"
[16:59] <vanhoof> brendand: http://paste.ubuntu.com/760626/
[17:13] <brendand> does anyone know if this bug was hardware specific? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/899165
[17:13] <ubot2> Launchpad bug 899165 in linux "uvcvideo: Failed to submit URB 0 (-28)." [Medium,In progress]
[17:14] <tgardner> brendand, looks like it is a generic EHCI bug
[17:15] <tgardner> of course, you only see it with isochronous connections
[17:28] <cking> mjg59, we've been  crowd-source testing your PCIe ASPM patch ( https://wiki.ubuntu.com/Kernel/PowerManagement ) and we're wondering if you know of any devices that may misbehave with this fix?  From the limited tests we've got so far it looks like a win 
[17:30] <sforshee> tgardner, wondering if you know the answer to this question. If a wireless card indicates that rfkill is applied, is that due to assertion of an external signal?
[17:30] <sforshee> i found a mini PCIe pinout that shows a "wireless disable" input signal
[17:32] <mjg59> cking: Nope, by the looks of it the machine responsible for the original patch should still work with this
[17:33] <tgardner> sforshee, its been awhile,. but I think its typically because the wifi driver has registered with the RFKILL API and is told by the platform rfkill driver that its been disconnected.
[17:34] <cking> mjg59, OK, we were worried it may enabled PCIe ASPM on some devices which may be problematic, but I suppose the new behaviour is more Windows like and hence will be less problematic in a sense
[17:36] <sforshee> tgardner, I'm not asking about the kernel support for rfkill, but what causes a generic wireless card to tell the driver to disable wireless. As an example, iwlagn has an interrupt status bit that will cause it to apply a block to the device (see iwl_irq_tasklet). I'm wondering what triggers the card to tell the driver that it should disable wirless.
[17:38] <tgardner> sforshee, dunno, but it seems like there must be some kind of HW support if its in the interrupt handler.
[17:41] <sforshee> tgardner, yeah, obviously. I'm just wanting enough evidence to conclude that something external to the card causes it to happen, as I suspect is the case. Thanks.
[17:42] <tgardner> sforshee, http://madwifi-project.org/wiki/UserDocs/MiniPCI
[17:44] <tgardner> seems pin 13 might be dedicated to this function
[17:44] <sforshee> tgardner, that's helpful, thanks. Now if I could only reproduce the problem so I could play with it ...
[17:44] <tgardner> sforshee, you could "Sellotape over pin 13" as suggested.
[17:45] <sforshee> tgardner, right, but since I can't reproduce the problem I wouldn't be able to tell whether or not it helps
[17:45] <tgardner> sforshee, ah, I thought you were having trouble getting the radio tuned on
[17:47] <sforshee> tgardner, no, this is pgraner's netbook. I can't reproduce his sudden disconnections no matter how hard I try
[17:47] <tgardner> sforshee, he was doing a bunch of disk copying over USB. have you tried that ?
[17:48] <sforshee> tgardner, not with USB. I generated a bunch of disk, network, and cpu activity (and got the temperature pretty high), but wireless remained stable
[17:49] <sforshee> i'll try that after i get back from lunch
[17:49]  * sforshee -> lunch
[18:00] <manjo> I have a 3TB disk that has 512 logical / 4096 physical sector size, when I use disk partition utility in 11.10 I get a warning that my partition is misaligned by 3072bytes and will impact performance ... any one have any suggestions on how I can fix that ? 
[18:00] <manjo> this is on a uefi 2.3.1 system 
[18:50]  * tgardner -> lunch
[18:51] <lamont> apw et al: armel builders are running (generally.. don't hold me to it): lucid (bbg3), maverick (beaglexm), natty (panda)
[18:52] <lamont> ppc is lucid
[18:52] <lamont> or maybe "lucid with maverick kernel" - don't remember.
[18:52] <lamont> everything else: hardy
[18:53] <lamont> given the slew in the armel family, I would be willing to entertain rolling all of arm to natty, if that makes people's life happier
[18:53] <lamont> the roll after this will be to precise, post-release, assuming that the kernel/distro folks are willing to support building hardy on precise for a little while
[18:54] <apw> lamont, that is an interesting issue indeed, infinity and i were talking about some of the issue the kernel version bump will trigger
[18:54] <apw> lamont, i wonder if there is value in getting something setup to allow us to test teh combinations
[18:55] <lamont> part of the reason they're still on hardy is because of dapper (now moot).
[18:55] <apw> lamont, particularly the xen side of things, as thats all shiney and new and may be broken
[18:56] <lamont> apw: the general rule is "most recent LTS, unless there's a really good reason otherwise"... hence maverick/natty for hw support
[18:56] <lamont> xen is the other reason
[18:57] <apw> lamont, any word on when the old beagles will die?  as they are not on a supported release now
[19:00] <lamont> apw: beagles are fine (*aceae.buildd) - bbg3 are the dead ones that infinity won't let me bury
[19:01] <lamont> seems there's a huge backlog of armhf builds to finish first
[19:01] <apw> :)  one or two i am sure, is there a plan to rip'em'out after thats caught up ?
[19:06] <herton> hggdh, do you know what is the status about linux-lts-backport-oneiric: 3.0.0-13.22~lucid1? (bug 885468). It's in QA for some time
[19:06] <ubot2> Launchpad bug 885468 in kernel-sru-workflow/regression-testing "linux-lts-backport-oneiric: 3.0.0-13.22~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/885468
[19:30] <hggdh> herton: finishing it now
[19:42] <TheLynx> hi
[19:43] <TheLynx> just a very short question... Does Thin provisioning is supported by dm-crypt? Or in other words is Thin provisioning a real virtualisation von every block of a device?
[19:50] <apw> TheLynx, not sure i know what thin provisioning means here, got a pointer to the meaning?
[19:50] <apw> though as it is virtualisation, #ubuntu-server may know better
[19:51] <TheLynx> http://en.wikipedia.org/wiki/Thin_provisioning it is used for iSCSI in my case
[19:53] <apw> i am unsure if you can have copy-on-write disks in device-mapper directly but non-fully populated disks and copy-on-write disks are common features of xen and kvm virtualisation at least
[19:57] <TheLynx> hmm this sounds good
[19:58] <TheLynx> at least, thank you for your help maybe someone from the open-iscsi team can answer this
[20:14] <Eimann> morning
[20:15] <Eimann> is there a reason why iwlwifi doesn't get build as a module in the daily/3.2 builds?
[20:24]  * herton -> eod
[23:59] <hallyn> any good suggestions for debugging acpi_wakeup_address?  (apart from printk, which I'll resort to if i have to)