| crimsun | BenC: pong, sorry for missing you. Spotty irc presence for an indeterminate time. | 00:31 |
|---|---|---|
| BenC | crimsun: no problem, I actually figured out what I wanted | 02:10 |
| BenC | crimsun: I was trying to figure out how the period/buffer stuff worked for alsa capture drivers, and I finally found the right documentation | 02:11 |
| BenC | crimsun: so my driver is working properly now :) | 02:13 |
| _pHI_ | hey! i was curious if TRIM support for SSDs was backported into the kernel that will ship with 10.04? | 02:37 |
| _pHI_ | afaik it only arrived with 2.6.33 | 02:37 |
| _pHI_ | any help would be great... | 02:55 |
| === lifeless_ is now known as lifeless | ||
| === ericm-afk is now known as ericm|ubuntu | ||
| toabctl | hi | 11:39 |
| toabctl | is it possible to create a devicenode (with udev rule) when a driver is loaded? e.g. if "mordprobe drivername": mknod ... | 11:39 |
| persia | toabctl: If the module discovers/enables some device, yes. | 11:42 |
| toabctl | persia, no. the device is a lcd-display (char device) and this won't be discovered | 11:43 |
| toabctl | persia, i can create the device-node by hand, but i would like to use udev to create the devicenode if the driver is loaded | 11:43 |
| toabctl | persia, my udev rule looks like this: DRIVER=="mylcdmodule", NAME="my-lcd" | 11:44 |
| persia | How is the LCD connected? | 11:44 |
| ogra | look at /lib/udev/rules.d/README | 11:44 |
| toabctl | persia, over gpios (it's a handmade solution) | 11:45 |
| persia | Oh, that's trickier indeed. Someone more knowledgeable than I needs to answer you. | 11:45 |
| toabctl | persia, i just thought that udev can do some action if a driver is loaded. | 11:46 |
| persia | I think you can, but I think you need a connect event: I hope I'm mistaken, so you can have an easy solution. | 11:46 |
| ogra | yes, you need a kernel event | 11:46 |
| toabctl | ogra, and a "module load" does not emit an event? | 11:47 |
| toabctl | ogra, i have to add the event to the module source code? | 11:47 |
| ogra | well, look at /var/log/udev when you load the module | 11:48 |
| ogra | you should see an "add" or "change" event | 11:49 |
| toabctl | ogra, thx. "udevadm monitor" is the command to help to debug the problem | 11:52 |
| ogra | ah, right | 11:52 |
| ogra | i forgot about that one | 11:53 |
| ogra | though the log should show essentially the same | 11:53 |
| toabctl | ogra, but how to handle the event? i got: UDEV [1272365579.494531] add /module/meteo40_lcd (module) | 11:54 |
| ogra | man udev should help you | 11:55 |
| persia | toabctl: If you have an event, just make a rule that matches it, and create your device. | 11:56 |
| toabctl | persia, i know that, but what is the event in my case? and how to match it? | 11:56 |
| persia | The event is "add /module/meteo40_lcd", from what you said | 12:00 |
| toabctl | persia, ACTION=="add", but what keyword should i use for "/module/meteo40_lcd" ? NAME?KERNEL? | 12:09 |
| persia | I'd go with trial and error on that one :) | 12:10 |
| persia | (although someone more knowledgeable may answer) | 12:10 |
| toabctl | persia, just if you are interessted: you can do: udevadm info -a -p /class/meteo40lcd | 12:28 |
| toabctl | then you see the information you need to write the correct rule. | 12:28 |
| persia | toabctl: Cool! Thanks for the hint. | 12:34 |
| * persia may have to add some rules for Displaylink devices in maverick | 12:35 | |
| === mdomsch is now known as mdomsch_BOS | ||
| exlt | I would like to know if 2.6.32.12 will be rolled into the Lucid release - they *finally* got the stable XFS patchset included, which fixes massive instability with the current version (we have been custom patching for quite a few releases..) | 13:25 |
| smb | exlt, IT will | 13:25 |
| smb | Not into release | 13:26 |
| exlt | \o/ | 13:26 |
| smb | Bit it will get into update | 13:26 |
| exlt | ah, ok | 13:26 |
| exlt | smb would you have a rough timeline of when that update might go out? just a guess is totally fine, so I can tell those at $JOB | 13:27 |
| * persia expects "a few weeks" is probably the right amount of precision to give in an official answer, to save smb needing to give a more correct answer on which someone might actually rely | 13:28 | |
| smb | exlt, There likely will be a security update in between. And UDS is ahead which slows things down | 13:28 |
| exlt | that all sounds perfect to me :) | 13:29 |
| smb | So yes some weeks sounds like something to be expected | 13:30 |
| * akgraner waves - Rikki said - She can connect to the internet wireless now - And even posted - "Who has the best Kernel Team? Ubuntu!" Y'all Rock! Thanks JFo and whomever else that helped!!! | 14:04 | |
| JFo | heh | 14:05 |
| JFo | I saw that | 14:05 |
| JFo | she is a mess | 14:05 |
| JFo | so now Tim knows that PPA kernel fixes her | 14:05 |
| akgraner | JFo, I told her it's cause I helped her file the bug :-) - she laughed | 14:05 |
| akgraner | Great - I am writing up how a simple FB post - can open all kinds on adventures from Learning how to file a bug, to showing developer channels aren't full scary unfriendly people but awesome helpful folks, and the list goes on.. - so thanks y'all :-) | 14:09 |
| * akgraner waves bye - laters | 14:09 | |
| arand | I reported Bug #514498 a while ago, and I was wondering whether or not any useful info at all might be extracted from the dd-copy? | 14:41 |
| ubot3 | Malone bug 514498 in linux "whole filesystem lost to corruption " [Medium,Triaged] https://launchpad.net/bugs/514498 | 14:41 |
| === kamalmostafa is now known as kamalm | ||
| JFo | arand, good question :) | 15:53 |
| JFo | apw, cnd do you know of anything we might be able to take away from a corrupted FS? | 15:54 |
| arand | JFo: Ah, you the triager? | 15:54 |
| JFo | arand has a dd image of it | 15:54 |
| cnd | I don't really know filesystems at all | 15:54 |
| JFo | arand, I am | 15:54 |
| JFo | csurbhi, how about you? | 15:54 |
| JFo | I know you know filesystems :-) | 15:55 |
| JFo | cnd, meant to put csurbhi there instead of you... sorry about that | 15:56 |
| cnd | JFo: np :) | 15:56 |
| arand | I'm not even sure if corruption after hard poweroff is "just the way things are", or were for the jaunty version of the kernel... | 15:59 |
| psurbhi | arand, I suspect the corruption occurs because of the hard poweroff | 16:02 |
| psurbhi | i can see this is lucid too, when the journal gets corrupted for instance. | 16:02 |
| arand | psurbhi: Yes, I suspected so as well, and it can be that repeated instances, even though fsck succeeds and everything seems fine, might "accumulate" corruption? Or would it always be a one-off fail? | 16:04 |
| psurbhi | if fsck succeeds, then fs should not be corrupted at that point | 16:05 |
| psurbhi | fsck should tell you when the fs is corrupted and beyond correction | 16:05 |
| psurbhi | arand, i will come back to you after looking what could be looked at to fix this up | 16:08 |
| psurbhi | thanks! | 16:08 |
| JFo | thank you for looking psurbhi | 16:09 |
| arand | psurbhi: ok cheers, if I'm not around here I follow the bug. | 16:09 |
| JFo | thanks for reminding me arand :) | 16:09 |
| arand | JFo: Yea, I wanted to make sure I didn't just forget it either ;) | 16:15 |
| === ogasawara_ is now known as ogasawara | ||
| Dink | Hello, I am trying to use launchpad to compile only a specific flavour kernel. I have edited i386.mk to only contain the flavour I want. How do I prepare this for launchpadd ppa to use? Are there any other files I need to edit ? Any help would be appreciated. | 19:33 |
| abogani | Dink: What should do your specific flavour? | 19:41 |
| Dink | its a strip down kernel for my netbook | 19:44 |
| Dink | I have never done this via .deb/ppa . I have done this before via rpm/opensuse build service | 19:45 |
| abogani | Dink: Why don't you create a -generic with a bigger number version? | 19:45 |
| Dink | I just found this link ... https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Preparing%20an%20upload | 19:45 |
| Dink | abogani, I do not want it to interfere with ubuntu's generic hence the different flavour | 19:45 |
| Dink | at time I do go back and fourth for testing etc, to me makes it easier | 19:46 |
| Dink | I am using the generic as my base | 19:46 |
| abogani | Dink: If you place that into you personal PPA you ever don't interfere with others. | 19:46 |
| Dink | Ahh I think I got it. Had to edit the first line in my changelog also | 20:01 |
| kamalm | I'm preparing my first patch submission to LKML -- the patch has already been applied to Lucid. I understand that I should put "Signed-off-by: ...myself..." in the patch description (as I did for the Lucid patch). I don't think anyone else has "signed off" on this patch, but apw did state "Acked-by: Andy W...". | 20:13 |
| kamalm | Question: Should I copy apw's Acked-by: line into the version of the patch going to LKML? Otherwise, is just my "S-o-b:" line sufficient for a submission to LKML? | 20:13 |
| achiang | kamalm: depends on whether apw was ack'ing your patch in the context of the lucid kernel or in the context of upstream. | 20:15 |
| kamalm | achiang: ah ha, I guess I should ask him. :-) | 20:15 |
| kamalm | Another question: I'm preparing the patch for LKML against the "mainline" tree (/pub/scm / linux/kernel/git/torvalds/linux-2.6.git) -- is the proper tree to base my patch from? | 20:16 |
| achiang | kamalm: in general, acked-by is somewhat "weak" tag. depending on the subsystem maintainer, they may interpret it differently. the most common use is if the maintainer has a few trusted reviewers who add their acked-bys. | 20:17 |
| achiang | kamalm: if i were to go ack a bunch of networking patches, e.g., i'm sure i would get yelled at by davem since i have no expertise there | 20:17 |
| kamalm | achiang: well maybe I just don't need to apply that Acked-by: to my LKML submission at all? | 20:17 |
| achiang | kamalm: in general yes, prepare against linus's tree, but again, sometimes depends on the subsystem | 20:18 |
| achiang | kamalm: right, without seeing your patch, it's hard to say | 20:18 |
| achiang | kamalm: care to post your patch (or a pointer)? | 20:18 |
| kamalm | certainly -- let me find it here. | 20:19 |
| kamalm | achiang: https://lists.ubuntu.com/archives/kernel-team/2010-April/010181.html | 20:20 |
| kamalm | achiang: https://lists.ubuntu.com/archives/kernel-team/2010-April/010188.html <--- andy's Acked-by response | 20:21 |
| achiang | kamalm: ok, so ACPI patch. for acpi, working off of linus's tree is fine | 20:21 |
| achiang | kamalm: as for adding andy's acked-by, i'm not entirely sure. you'd have to ask him, i guess | 20:22 |
| achiang | kamalm: you can add mine though. :) | 20:22 |
| achiang | Acked-by: Alex Chiang <achiang@canonical.com> | 20:22 |
| kamalm | achiang: oh, okay, I'll add yours and not add andy's, since he's not around to ask. thanks very much for the advice. :-) | 20:23 |
| achiang | kamalm: i'm actually waiting on this one: https://patchwork.kernel.org/patch/94711/ | 20:23 |
| achiang | kamalm: i'll probably poke lenb today; he's been travelling so i wanted to give him some time to work through his backlog | 20:24 |
| kamalm | achiang: ah, your thinkpad patch is exactly the same issue eh? I'm wondering whether it would be possible to move the DMI-detection for this down into udev and just have the kernel respond to a binary switch to do the sci_en thing or not based on whatever udev said to do. does that sound plausible to you? | 20:25 |
| achiang | kamalm: for your patch, please do cc: stable@kernel.org too | 20:25 |
| achiang | kamalm: hm, what you suggest sounds possible, but it's not common for how we handle acpi quirks | 20:26 |
| kamalm | achiang: ok, will do -- does cc'ing stable@ mean that I'm requesting that the patch be applied to the stable kernel as well as mainline then? | 20:26 |
| achiang | yes, that's what you're requesting | 20:26 |
| achiang | kamalm: in the context of these bugs, we're basically getting little band-aids upstream to help distros out. the fix going forward will be this patch:https://patchwork.kernel.org/patch/93560/ | 20:27 |
| achiang | kamalm: so basically, get this quirks added upstream, get them into stable to help out distros, and hopefully with mjg59's fix we don't have to add to the DMI table any more in the future | 20:28 |
| kamalm | achiang: the detect-it-in-udev concept is how the keyboard map quirks seem to work, which is what gave me the idea of doing the sci_en that way also -- i had heard about the "forthcoming better way" -- thanks for the pointer -- no need to pursue a better band-aid mechanism then. :-) | 20:29 |
| cnd | kamalm: achiang: you don't cc stable@kernel.org directly though | 21:18 |
| cnd | you add a "Cc: stable@kernel.org" line to the s-o-b area | 21:19 |
| cnd | you can ask csurbhi all about the fun you'll get from gregkh if you start CC'ing patches directly to stable@kernel.org | 21:19 |
| achiang | cnd: hm, i add the cc to the sign-off area and also in my mailer | 21:20 |
| achiang | cnd: i haven't been yelled at yet. ;) | 21:20 |
| cnd | achiang: if you have the Cc in the s-o-b area, it will get sent to stable@kernel.org when linus applies it to his tree | 21:21 |
| cnd | so that way only patches which are actually applied get sent | 21:21 |
| achiang | cnd: interesting, i hadn't realized that | 21:21 |
| kamalm | cnd: yes thanks for that tip! (very timely too!) | 21:22 |
| achiang | does linus have a special git hook to do that? | 21:22 |
| cnd | if you cc stable@kernel.org directly, then gregkh gets a bunch of patches that may or may not actually be in linus' tree | 21:22 |
| cnd | achiang: I'm not sure | 21:22 |
| cnd | and it may be further down the line at the subsystem maintainers level for all I know | 21:22 |
| cnd | but I have had a patch accepted to stable that way, so I can vouch for it :) | 21:22 |
| achiang | because that's not standard kernel patch flow at least not in the areas i'm familiar with -- simply adding a git tag to the signed off area doesn't automatically result in an email | 21:23 |
| cnd | achiang: I have a feeling if you start to send a few more you may hear from gregkh about it :) | 21:23 |
| achiang | maybe stable is special | 21:23 |
| cnd | stable isn't like any other subsystem though | 21:23 |
| cnd | it's rather *special* | 21:23 |
| achiang | yup, i'm guessing a fancy hook | 21:24 |
| achiang | cnd: anyhow, good info to have, thanks | 21:24 |
| === lifeless_ is now known as lifeless | ||
| cnd | only stuff that is applied upstream should make it to the stable trees | 21:24 |
| cnd | in general, if you're unsure, check the Documentation directory of the tree | 21:25 |
| cnd | it has a whole txt file devoted to stable tree submissions | 21:25 |
| cnd | all about what's appropriate and how to get changes accepted | 21:25 |
| cnd | for example, it's always good to CC the subsystem maintainers if you're taking an upstream patch and asking it to be applied to stable | 21:26 |
| cnd | and to add a note about regression potential in that case too | 21:26 |
| cnd | if it's a rather large change, it may be easier to get the subsystem maintainer to push it to stable as well | 21:26 |
| cnd | there's a little bit of a trust issue there, for better or worse depending on your point of view | 21:26 |
| kamalm | I discovered that scripts/get_maintainer.pl generates a nice list of all the right people/lists to email, given a patch file -- good stuff. | 21:27 |
| cnd | kamalm: hmmm, hadn't noticed that file, good find | 21:28 |
| cnd | kamalm: also, run your patches through scripts/checkpatch.pl before submitting | 21:28 |
| cnd | it finds format issues | 21:28 |
| kamalm | cnd: re checkpatch.pl - neato! its happy with my patch | 21:30 |
| cnd | great! | 21:30 |
| achiang | i've discovered that turning 'let c_space_errors=1' on in my .vimrc helps quite a bit | 21:39 |
| cnd | achiang: is that what turns ws red in git diff? | 21:42 |
| cnd | I wouldn't mind having that on all the time too... | 21:42 |
| achiang | cnd: no, that is something you set in your ~/.gitconfig | 21:42 |
| achiang | cnd: oh, nm -- if you colorize git, then you get whitespace color for free without twiddling your .gitconfig | 21:43 |
| cnd | achiang: yeah, I get it automatically in git diff | 21:43 |
| cnd | just not in vim | 21:43 |
| achiang | but you can set other whitespace options in there: core.whitespace (not common) and apply.whitespace (much more common) | 21:44 |
| achiang | cnd: that vim option lets you see whitespace errors in your editor, so you can write perfectly formatted patches. :) | 21:44 |
| achiang | it can be a little annoying when you view files in the kernel with broken whitespace | 21:45 |
| cnd | heh | 21:45 |
| achiang | kamalm: next time, reverse the order of your git tags. :) | 22:12 |
| kamalm | um... what do you mean? | 22:13 |
| achiang | cc: stable goes first, cc: me next, s-o-b last | 22:13 |
| achiang | you read that sign off area from top to bottom, so the top has informational stuff, like cc's, reviewed-by:, acked-by: etc. | 22:14 |
| achiang | then in order of patch delivery, you add s-o-bs | 22:14 |
| achiang | so original author is topmost, and last hop in the delivery path is you | 22:14 |
| kamalm | achiang: oh, I guess I didn't even realized that the order there even mattered. I'll try to remember that for next time. thanks! | 22:15 |
| achiang | kamalm: you're right, it doesn't matter so much, but it is a nicety that makes it a little easier to read. that's all. :) | 22:15 |
| achiang | the s-o-bs are important to get in order | 22:15 |
| kamalm | achiang: got it -- luckily, there's only one s-o-b for this one! | 22:16 |
| achiang | yup | 22:16 |
| cnd | kamalm: it's a little overwhelming, all the processes :) | 22:24 |
| cnd | rest assured, three months in (like me), you'll still be spinning around, but you'll have a better idea of how things go :) | 22:25 |
| kamalm | cnd: sure is overwhelming, but yes, its all becoming clearer with each passing day -- thanks very much to you and achiang for the help! | 22:25 |
| * maco didn't know it mattered either | 22:26 | |
| achiang | think of the s-o-b's as a path a patch takes to get upstream | 22:26 |
| achiang | each person involved in the patch submission appends his/her sob to the path | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!