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