| 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 | 00:46 |
| === smb` is now known as smb | ||
| smb | morning .+ | 07:45 |
| apw | morning | 07:50 |
| BigWhale | Greetings | 08:08 |
| 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:09 |
| 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:10 |
| BigWhale | apw: well I just got new motherboard and noticed the problem now. :) | 08:11 |
| BigWhale | well it is sort of working | 08:11 |
| 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:12 |
| apw | BigWhale, hang on isn't that a wired card thats reporting errors ? | 08:13 |
| BigWhale | it is a wired card yes | 08:13 |
| apw | so its working ok other than log spam ? | 08:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| BigWhale | r8168.ko which is odd since it used to be r8169.ko :> | 08:18 |
| 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:19 |
| BigWhale | well the driver itself is for multiple cards... | 08:20 |
| BigWhale | but not for 8169 :> | 08:20 |
| BigWhale | Now I am starting to wonder if this new module will autoload | 08:22 |
| apw | well i doubt it will | 08:23 |
| BigWhale | apw, kernel will probably look for r8169.ko | 08:24 |
| 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:27 |
| BigWhale | I can see that openSuse guys had/have the same problem | 08:28 |
| BigWhale | *curses* what is the package name for kernel? :> | 08:28 |
| apw | BigWhale, realtek are renouned for this issue | 08:29 |
| apw | kernel == linux | 08:29 |
| BigWhale | ah, thanks | 08:30 |
| BigWhale | is launchpad acting up? it seems I can't report new bugs?! | 08:33 |
| BigWhale | Oops! | 08:33 |
| apw | BigWhale, for you you may find blacklisting r8169.ko in /etc/modprobe.d might make the other one preferred | 08:41 |
| BigWhale | I'll reboot now and see what happens... | 08:43 |
| BigWhale | :> | 08:43 |
| === NCommander is now known as Guest93709 | ||
| === yofel_ is now known as yofel | ||
| 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:21 |
| apw | txomon, not sure i know what you mean by a "documentation program" | 10:27 |
| apw | txomon, configs are self documented if you are looking to see what they do ? | 10:28 |
| 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:30 |
| 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:31 |
| txomon | ok.. so for each option I should UFG ? (Use th F Google) | 10:37 |
| 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:44 |
| 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:53 |
| 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:54 |
| txomon | thank you btw | 10:55 |
| txomon | Can I add comments in the config_old ? | 10:55 |
| 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:56 |
| 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! | 10:57 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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 | 11:10 |
| 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:53 |
| 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 | 12:54 |
| apw | anyone point me at a conversion between mAh and mWh ? | 13:28 |
| 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:29 |
| 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:56 |
| 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 | 13:58 |
| * 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:34 |
| apw | brendand, ^^ | 14:37 |
| 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:38 |
| apw | then the whole life cycle would be represented in the one place ? | 14:39 |
| bjf | apw, but that wasn't the purpose of that report and i believe it would add confusion to others that view it | 14:40 |
| bjf | apw, i could add just the version in the ppa like what's on: http://people.canonical.com/~kernel/reports/versions.html | 14:43 |
| 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:45 |
| bjf | brendand, http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html | 14:46 |
| bjf | brendand, does that have what you are looking for ? | 14:51 |
| brendand | bjf - perfect | 15:27 |
| * herton -> lunch | 15:55 | |
| apw | is anyone else getting asked for the passowrd for their wireless everytime they resume ? | 15:58 |
| smb | apw, nope | 16:03 |
| 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:04 |
| * 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:05 | |
| 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:06 |
| 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:07 |
| tgardner | apw, drag a cable out there :) | 16:08 |
| apw | tgardner, tempting indeed | 16:09 |
| tgardner | apw, until someone slams the sliding door shut | 16:10 |
| apw | heh, ouch :( | 16:10 |
| === s1aden is now known as sladen | ||
| 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:12 |
| 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:13 |
| apw | tgardner, added to my todo, there seems to be another perl-y one on there too will have a look | 16:14 |
| tgardner | apw, I'm working on an alternative for the kernel package, but fixing dh-gencontrol would help others to parallelize their packaging. | 16:16 |
| === soren_ is now known as soren | ||
| apw | tgardner, sounds reasonable to moi | 16:17 |
| 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:22 |
| komputes | Does anyone know why uname -a now shows arch 3 times? | 16:43 |
| broder | komputes: it's "machine", "processor", and "hardware platform" | 16:47 |
| 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:05 |
| * bjf is rebooting | 17:15 | |
| * tgardner -> lunch | 17:30 | |
| 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? | 17:52 |
| * jjohansen -> lunch | 19:01 | |
| * bjf -> lunch | 19:03 | |
| * ogasawara lunch | 19:08 | |
| 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:57 |
| hallyn_ | should have been obvious to me from the start.... | 19:58 |
| ppetraki | hmm, that isn't much different from someone changing the state of an SD device to offlline or echo 1 > delete | 20:01 |
| 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:05 |
| 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:06 |
| ppetraki | so unless we can come up with a better solution, we'll have to work around it | 20:07 |
| hallyn_ | ppetraki: terrific | 20:31 |
| hallyn_ | ppetraki: though that is for scsi. I'm not sure what paths the nbd driver takes. Lemme take a look | 20:32 |
| ppetraki | hallyn_, well, hotplug is hotplug | 20:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| ppetraki | hallyn_, so you basically want to block disconnect until the write-back has a chance to complete? | 20:40 |
| 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:41 |
| 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:42 |
| ppetraki | hallyn_, the right answer here may just be "don't do that" | 20:43 |
| sconklin | tgardner, fixed, thanks! | 20:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| hallyn_ | ppetraki: anyway i may pursue a patch doing -EBUSY tomorrow afternoon. | 20:49 |
| 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:50 |
| hallyn_ | wouldn't be my first lkml rejection experience :) | 20:53 |
| ppetraki | hallyn_, actually, nbd has it's own list | 20:57 |
| 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:58 |
| ppetraki | hallyn_, well, userspace programs generally can't dictate when a kernel resource decides to quit, unless a reference count was taken | 20:59 |
| hallyn_ | no but they can refuse to tell the kernel to shoot itself in the foot | 21:00 |
| ppetraki | hallyn_, oh wait, the unmount is occuring in the guest? | 21:02 |
| ppetraki | hallyn_, nm, looking at your script | 21:03 |
| hallyn_ | ppetraki: yeah for the script, ignore any mention of clouds or virt | 21:04 |
| hallyn_ | it just runs on the host | 21:04 |
| 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:05 |
| ppetraki | hallyn_, right, the journal is in flight so you never get it all. | 21:06 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| ppetraki | hallyn_, I like that one best, you'd also have to consider raw io, no superblocks to check there, just open count. | 21:13 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!