[00:46] <Laibsch> Can somebody help and identify the kernel patches that apparently fixed bug 745836 in oneiric?  They are in desperate need to be backported to maverick, natty and lucid.
[00:46] <ubot2> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] https://launchpad.net/bugs/745836
[07:45] <smb> morning .+
[07:50] <apw> morning
[08:08] <BigWhale> Greetings
[08:09] <BigWhale> Who do I have to talk to, to get the latest RTL8111E driver in the Oneiric? :) The one that is currently present is acting really strange.
[08:09] <BigWhale> and isn't what I would call a production quality :/
[08:09] <ogra_> nobody does
[08:10] <apw> BigWhale, its a bit late in the day for those kind of size changes, thats why we have alphas
[08:10] <cking> hope it's not a case of "if it compiles then ship it"
[08:11] <BigWhale> apw: well I just got new motherboard and noticed the problem now. :)
[08:11] <BigWhale> well it is sort of working
[08:12] <BigWhale> just dmesg is full of [  493.664950] r8169 0000:04:00.0: eth1: link up
[08:12] <BigWhale> every second or so
[08:12] <BigWhale> I'll file a bug report ...
[08:13] <apw> BigWhale, hang on isn't that a wired card thats reporting errors ?
[08:13] <BigWhale> it is a wired card yes
[08:14] <apw> so its working ok other than log spam ?
[08:15] <BigWhale> apw, but this is not really nice: http://pastebin.com/wp2PwNAa
[08:15] <BigWhale> apw, no it is not working as it should... packets are being dropped
[08:15] <apw> well indeed file a bug, never know might be fixable
[08:15] <BigWhale> I installed latest driver from realtek and it is working correctly
[08:16] <apw> yeah but their stupid drivers arn't exactly designed to be integrated in a way which works with everything else
[08:16] <apw> those guys need a serious reality check
[08:17] <BigWhale> perhaps that's why their installation script didn't work and I had to compile it manually and copy it to /lib/modules/... :>
[08:17] <apw> BigWhale, likely, what driver name did it make
[08:18] <BigWhale> r8168.ko which is odd since it used to be r8169.ko :>
[08:19] <apw> BigWhale, see what i mean, you got a driver for one card and it makes a driver which would replace all drivers for that name ... bah
[08:20] <BigWhale> well the driver itself is for multiple cards...
[08:20] <BigWhale> but not for 8169 :>
[08:22] <BigWhale> Now I am starting to wonder if this new module will autoload
[08:23] <apw> well i doubt it will
[08:24] <BigWhale> apw, kernel will probably look for r8169.ko 
[08:27] <apw> BigWhale, and this just demonstrates my point, their drivers are hopeless integration wise
[08:27] <apw> why they cannot work with teh upstream kernel and give us and you a fighting chance i have no idea
[08:28] <BigWhale> I can see that openSuse guys had/have the same problem
[08:28] <BigWhale> *curses* what is the package name for kernel? :>
[08:29] <apw> BigWhale, realtek are renouned for this issue
[08:29] <apw> kernel == linux
[08:30] <BigWhale> ah, thanks
[08:33] <BigWhale> is launchpad acting up? it seems I can't report new bugs?!
[08:33] <BigWhale> Oops!
[08:41] <apw> BigWhale, for you you may find blacklisting r8169.ko in /etc/modprobe.d might make the other one preferred
[08:43] <BigWhale> I'll reboot now and see what happens...
[08:43] <BigWhale> :>
[10:21] <txomon> hi, does anyone know about any kernel config's documentation program? I need to build a very specific kernel for a 16core computer
[10:27] <apw> txomon, not sure i know what you mean by a "documentation program"
[10:28] <apw> txomon, configs are self documented if you are looking to see what they do ?
[10:30] <txomon> apw, I am looking for specific knowledge about each value of the menuconfig, to know if it is adequate for me
[10:30] <apw> txomon, beyond what is documented in the help for each option i don't know of more detailed information
[10:31] <txomon> I meant if there was any "kernel-config documentation project"
[10:31] <txomon> something like that
[10:31] <apw> there are a heck of a lot of them it doesn't seem feasable to look a tthem all
[10:31] <apw> txomon, no not to my knowledge anyhow
[10:37] <txomon> ok.. so for each option I should UFG ? (Use th F Google)
[10:44] <apw> txomon, most options have extensive help on them, several paragraphs of description
[10:44] <apw> which should be exposed in the menu config
[10:53] <txomon> apw, commonly yes, but sometimes, it is not enough, as I don't know how to retrieve data to decide whether if that option is good for me
[10:54] <apw> txomon, you must have some very tight requirements, good luck
[10:54] <txomon> I my research group we are working in a kernel module that occupies all the CPU, and we want to optimize it
[10:55] <txomon> thank you btw
[10:55] <txomon> Can I add comments in the config_old ?
[10:56] <txomon> I mean, If I compile for the next kernel, it will tell me that there has been found a new config_old, and I was wondering if in the new config file comments would be still there
[10:57] <apw> i don't beleieve that it will honour them no, i think it rebuild it from its internal representation
[10:57] <txomon> ok, so I will have to /replace
[10:57] <txomon> thank you!
[11:03] <brendand> does anyone know why this page isn't updating : http://people.canonical.com/~kernel/reports/sru-report.html?
[11:03] <brendand> the info looks out of date
[11:03] <apw> brendand, what about it looks out of date ?
[11:04] <apw> Friday, 30. September 2011 11:01 UTC
[11:04] <apw> it seems to think it updated itself 'just now'
[11:04] <brendand> yeah, but e.g. there is no reference to the natty -proposed tracking bug
[11:05] <apw>      linux | 2.6.38-11.50 | natty-security | source
[11:05] <apw>      linux | 2.6.38-11.50 | natty-updates | source
[11:05] <apw> natty seems to have no more up to date version ?
[11:05] <apw> ie it is released ?
[11:07] <apw> hmm but there is a 12.51 build and ready to go, hmmm wonder why its not listed, i wonder if it lists things before they are in -proposed
[11:07] <brendand> apw - it normally shows the tracking bug, i.e. this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/860832
[11:07] <ubot2> Launchpad bug 860832 in linux "linux: 2.6.38-12.51 -proposed tracker" [Medium,In progress]
[11:08] <brendand> i thought it showed the tracking bug through its entire life
[11:08] <apw> brendand, it cirtainly makes sense that it might, you are beyond my understanding now, as it is updating at least
[11:08] <apw> i'd have to refer you to sconklin and herton
[11:10] <brendand> apw - i'll have to wait then. thanks
[11:10] <apw> sorry about that, i'll have to get some knowledge transfer on it
[12:53] <apw> herton, the latest natty kernel tracking bug seems to be missing from: http://people.canonical.com/~kernel/reports/sru-report.html
[12:53] <apw> (brendend reported it)
[12:54] <herton> apw: I think that's because the current natty update wasn't copied yet to -proposed, but better check with brad
[12:54] <apw> bjf, ^^
[12:54] <apw> herton, i was assuming the contents of the build PPA was on there too ... hmmm, will wait on brad
[13:28] <apw> anyone point me at a conversion between mAh and mWh ?
[13:29] <sconklin> apw, it depends on voltage,
[13:29] <sconklin> mWh = mAh * voltage
[13:29] <apw> sconklin, it is a little odd that some machines report battery capacity in one, and otehrs the other
[13:56] <brendand> herton - do you know is this page updating properly? the section on natty at least seems to be wrong - http://people.canonical.com/~kernel/reports/sru-report.html
[13:58] <apw> ahhh wern't you here, the discusssion was that we weren't sure and bjf is in the frame for answering now
[13:58] <herton> yes, I think the page only shows when things are copied to -proposed, latest natty isn't copied to -proposed yet
[14:34]  * bjf seems to be popular this morning, maybe he should just go back to bed
[14:34] <bjf> apw, herton is correct, the tracking bug should only show up on that page when the package has reached -proposed
[14:37] <apw> brendand, ^^
[14:38] <apw> bjf, would it be hard to add a new psudo pocket of like -build which had what was in the PPA
[14:38] <bjf> apw, why?
[14:39] <apw> then the whole life cycle would be represented in the one place ?
[14:40] <bjf> apw, but that wasn't the purpose of that report and i believe it would add confusion to others that view it
[14:43] <bjf> apw, i could add just the version in the ppa like what's on: http://people.canonical.com/~kernel/reports/versions.html
[14:45] <apw> bjf yeah unsure not really a big consumer of it either way
[14:45] <brendand> bjf - can you recommend a quick way to find the current tracking bug without going back through email?
[14:46] <bjf> brendand, http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[14:51] <bjf> brendand, does that have what you are looking for ?
[15:27] <brendand> bjf - perfect
[15:55]  * herton -> lunch
[15:58] <apw> is anyone else getting asked for the passowrd for their wireless everytime they resume ?
[16:03] <smb> apw, nope
[16:04] <apw> starting to get on my nerves
[16:04] <tgardner> apw, testing....
[16:04] <apw> perhaps i am too many milliseconds behind the bleeding edge
[16:04]  * smb has not upgraded for 2 days...
[16:04] <apw> smb, yeah it was ok a couple of days ago
[16:04]  * bjf neither, been afraid
[16:04]  * smb probably won't do that then
[16:04] <tgardner> apw, I just upgrade 15 minutes ago
[16:05]  * bjf dist-upgrading right now (will probably regret it)
[16:05] <tgardner> apw, so it resumed and connected OK, but I didn't get the screen lock login.
[16:05]  * apw giggle
[16:06] <tgardner> apw, I wonder if thats because I have screen lock turned off
[16:06] <apw> apparently i am 169 packages out of date _again_ so, i'll shut up until i've upgraded yet more
[16:06] <tgardner> apw, yeah, I picked up 60 or so this AM
[16:07] <bjf> i am 185 behind
[16:07] <apw> bah my wifi is degraded out here on the balcony ... sigh
[16:07] <apw> how can this be, my house is made of sheets of paper
[16:08] <tgardner> apw, drag a cable out there :)
[16:09] <apw> tgardner, tempting indeed
[16:10] <tgardner> apw, until someone slams the sliding door shut
[16:10] <apw> heh, ouch :(
[16:12] <tgardner> apw, hey, while you're just scoping the great outdoors, how about having a look at /usr/bin/dpkg-gencontrol with an eye towards developing a patch the protects multiple writers to debian/files. cjwatson suggested using the flock primitive.
[16:13] <tgardner> my perl foo is a bit weak these days
[16:13] <apw> tgardner, is that what is stopping us from doing parallel builds ?
[16:13] <tgardner> apw, I think its the source of random errors
[16:14] <apw> tgardner, added to my todo, there seems to be another perl-y one on there too will have a look
[16:16] <tgardner> apw, I'm working on an alternative for the kernel package, but fixing dh-gencontrol would help others to parallelize their packaging.
[16:17] <apw> tgardner, sounds reasonable to moi
[16:22] <bjf> apw, i dist-upgraded, suspended, resumed, did not get prompted for ap password
[16:22] <apw> bjf heres hoping i'll be ok once i update then
[16:43] <komputes> Does anyone know why uname -a now shows arch 3 times?
[16:47] <broder> komputes: it's "machine", "processor", and "hardware platform"
[17:05] <komputes> broder: sorry i'm still a bit confused. by that logic wouldn't a processor capable of doing 64-bit cause uname to show i686 x86_64 1386
[17:15]  * bjf is rebooting
[17:30]  * tgardner -> lunch
[17:52] <tkamppeter> I have an old 32-bit HP Compaq 12-inch laptop and it does not boot with the 3.0.0-12 kernel, but only with the last Natty kernel. How to report a bug/debug this?
[19:01]  * jjohansen -> lunch
[19:03]  * bjf -> lunch
[19:08]  * ogasawara lunch
[19:57] <hallyn_> smb: ppetraki: at least, a simple reproducer script for bug 861656 .
[19:57] <ubot2> Launchpad bug 861656 in linux "many ext4 errors " [Undecided,Confirmed] https://launchpad.net/bugs/861656
[19:58] <hallyn_> should have been obvious to me from the start....
[20:01] <ppetraki> hmm, that isn't much different from someone changing the state of an SD device to offlline or echo 1 > delete
[20:05] <ppetraki> whatever framework is managing this, or the user, that's their problem. There has been a push recently to try communicate "use count" to lower layer devices in the case of virtualization, but it was not well received.
[20:05] <ppetraki> hallyn_, http://www.spinics.net/lists/linux-scsi/msg54687.html
[20:06] <tkamppeter> I have an old 32-bit HP Compaq 12-inch laptop and it does not boot with the 3.0.0-12 kernel, but only with the last Natty kernel. How to report a bug/debug this?
[20:06] <ppetraki> hallyn_, and the nak: http://www.spinics.net/lists/linux-scsi/msg54688.html
[20:07] <ppetraki> so unless we can come up with a better solution, we'll have to work around it
[20:31] <hallyn_> ppetraki: terrific
[20:32] <hallyn_> ppetraki: though that is for scsi.  I'm not sure what paths the nbd driver takes.  Lemme take a look
[20:34] <ppetraki> hallyn_, well, hotplug is hotplug
[20:35] <tgardner> sconklin, GPG sign your entry at https://wiki.ubuntu.com/HertonKrzesinski/PerPackageUploaderApplication
[20:35] <ppetraki> hallyn_, now this nbd thing *may* have an additional interface where this count could be determined 
[20:36] <hallyn_> right that's my hope
[20:36] <ppetraki> hallyn_, I hate to dash your hopes but it probably doesn't have one
[20:36] <sconklin> tgardner, really? This hasn't been widely done or enforced in the past. But whatever.
[20:36] <tgardner> sconklin, I'm just following directions....
[20:37] <sconklin> heh, and I'm was flagrantly igoring them. Having been busted, I'll go fix it.
[20:37] <hallyn_> ppetraki: i'll be ok :)
[20:37] <ppetraki> hallyn_, heh
[20:39] <hallyn_> ppetraki: though, i nbd_ioctl gets a struct block_device().  Seems like adding a check over the list of mounted supers shouldn't be a big deal...
[20:39] <hallyn_> (at NBD_DISCONNECT)
[20:40] <ppetraki> hallyn_, so you basically want to block disconnect until the write-back has a chance to complete?
[20:41] <ppetraki> hallyn_, that could get confusing quick, as in if it's due to a transport error, that flush may never occur and block forever.
[20:41] <hallyn_> yes, just return -EBUSY
[20:41] <hallyn_> true
[20:42] <ppetraki> hallyn_, so adding more transparency to the supers wouldn't be a big deal but now you just gave userspace more to chew on, and take action subjectively.
[20:43] <ppetraki> hallyn_, the right answer here may just be "don't do that"
[20:44] <sconklin> tgardner, fixed, thanks!
[20:45] <hallyn_> ppetraki: it's just an ioctl... returning -EBUSY seems fine
[20:45] <hallyn_> ppetraki: the problem is, it's not just "don't do that."  Because if you do
[20:46] <hallyn_> well, bc the umount may fail :)
[20:46] <ppetraki> hallyn_, so looking back at the bug, you state that nbd starts dropping out under load.
[20:47] <hallyn_> oh, disgregard most of what i wrote there
[20:47] <ppetraki> gee thanks :)
[20:47] <hallyn_> in the end, the little script is all you need.  no load needed
[20:48] <hallyn_> heh, that's why i said "i should've seen it earlier" - i was chasing down the idea of ext4 or nbd corruption due to high load
[20:49] <hallyn_> ppetraki: anyway i may pursue a patch doing -EBUSY tomorrow afternoon.
[20:50] <ppetraki> hallyn_, you can try, though I don't think it'll be accepted. block devices, and generally block device stacking depend on the current behavior. Special casing NBD isn't a "good thing"
[20:50] <ppetraki> hallyn_, I can rip out a multipath device right now from a mount and the kernel can't stop me
[20:53] <hallyn_> wouldn't be my first lkml rejection experience :)
[20:57] <ppetraki> hallyn_, actually, nbd has it's own list
[20:58] <hallyn_> i don't want to be on another list :(
[20:58] <hallyn_> ppetraki: i'm still thinking - wondering if it should go in qemu/qemu-nbd.c instead
[20:59] <ppetraki> hallyn_, well, userspace programs generally can't dictate when a kernel resource decides to quit, unless a reference count was taken
[21:00] <hallyn_> no but they can refuse to tell the kernel to shoot itself in the foot
[21:02] <ppetraki> hallyn_, oh wait, the unmount is occuring in the guest?
[21:03] <ppetraki> hallyn_, nm, looking at your script
[21:04] <hallyn_> ppetraki: yeah for the script, ignore any mention of clouds or virt
[21:04] <hallyn_> it just runs on the host
[21:05] <ppetraki> hallyn_, hmmm, best thing to do here is flush on exit from qemu-nbd -d, and kill the queue so it won't accept any new requests. Then the unmount won't have anything to flush
[21:05] <ppetraki> hallyn_, you should update the description :-p
[21:05] <hallyn_> ppetraki: i did
[21:05] <hallyn_> it's now called Kernel oops when nbd device is removed before it is unmounted 
[21:06] <ppetraki> hallyn_, right, the journal is in flight so you never get it all. 
[21:09] <ppetraki> hallyn_, I'm still not a huge fan of the use case.
[21:09] <hallyn_> ppetraki: i think it's worse than that.  it's not a corrupt fs in the guest i'm worried about.  it's submit_bh() on the host doing opcode 0000
[21:09] <hallyn_> [ 6016.938260] invalid opcode: 0000 [#1] SMP 
[21:09] <hallyn_> use case?
[21:10] <ppetraki> hallyn_, the script, if you just swapped qemu-nbd -d /dev/nbd1 and mount /mnt/1, the problem disappears right?
[21:10] <hallyn_> of course :)
[21:11] <ppetraki> hallyn_, yeah, I don't like that use at all, again, it's a block device, no different than any other.
[21:11] <hallyn_> ppetraki: the idea isn't that you didn't do umount.  It's that you did umount but umount failed (i.e. a file on the fs was open)
[21:11] <hallyn_> yeah, it's just easier to shoot yourself this way
[21:11] <ppetraki> hallyn_, now, if you were to perhaps change qemu-nbd -d to add say a --lazy switch, that might be a good way around
[21:12] <ppetraki> hallyn_, then you're giving people the choice of whether to destroy that resource once it's users have left
[21:12] <hallyn_> that'd be nice, yes
[21:12] <hallyn_> but like i say i think i'll ignore it for nwo and just fix the caller that's bugging me
[21:13] <ppetraki> hallyn_, I like that one best, you'd also have to consider raw io, no superblocks to check there, just open count.