Ubuntu Wiki

Ubuntu Open Week - Reporting and Fixing Kernel Bugs - Leann Ogasawara - Mon, Nov 3rd, 2008

(12:00:19 PM) ogasawara: Hi Everyone!
(12:00:27 PM) ogasawara: Welcome to the session on Reporting and Fixing Kernel Bugs!
(12:00:38 PM) ogasawara: My name is Leann Ogasawara and I work for Canonical as a member of the Ubuntu QA Team.  My primary focus is on the Ubuntu kernel bugs.
(12:00:50 PM) ogasawara: I'd really like to spend the next hour highlighting some kernel bug reporting best practices and getting fixes incorporated into the Ubuntu kernel.
(12:01:04 PM) ogasawara: If anyone has questions along the way, feel free to post them in #ubuntu-classroom-chat and I'll try to answer as many as I can.
(12:01:20 PM) ogasawara: Let's gets started.
(12:01:35 PM) ogasawara: Beginning with the Hardy Heron 8.04 release the Ubuntu kernel package naming convention in Launchpad changed from linux-source-2.6.xx to just linux.
(12:01:48 PM) ogasawara: Ubuntu kernel bugs should be filed against the "linux" kernel package.  This can be done using the following link:
(12:01:57 PM) ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
(12:02:04 PM) ogasawara: It's important to make sure the bug is filed against the linux package to help ensure it gets looked at by the kernel team.
(12:02:14 PM) ogasawara: When filing a bug, please make sure the title of the bug report is descriptive.
(12:02:23 PM) ogasawara: Don't use something like "Suspend Fails" or "Wireless is broken".
(12:03:00 PM) ogasawara: It's better to use for example "Suspend fails to resume on a Dell Inspiron 1420".
(12:03:13 PM) ogasawara: Always include hardware or driver information in a kernel bug's title when applicable.
(12:03:25 PM) ogasawara: The reason I say this is because kernel bugs are often hardware specific.
(12:03:33 PM) ogasawara: Even though someone may be experiencing the same symptom of a bug, they should really open a new report if they have different hardware than the original bug reporter.
(12:03:46 PM) ogasawara: Different hardware uses different drivers which likely require different fixes, hence the reason for separate bug reports.
(12:03:57 PM) ogasawara: This is why I stress the importance of a descriptive bug title.  When something like "Suspend Fails" is used as the title, everyone with suspend/resume issues ends up subscribing to the bug.
(12:04:15 PM) ogasawara: This invites others to post completely unrelated information to the bug.  Even worse, the bug will often get a flurry of "me too" comments posted.
(12:04:27 PM) ogasawara: This results in impossible to follow bug reports which are not likely to get much attention from the kernel team.
(12:04:41 PM) ogasawara: Also, please refrain from posting the "I think I'm having the same bug . . ." type of comments.  If someone is unsure if they have the same bug, open a new report.
(12:04:59 PM) ogasawara: Hijacking another person's bug report is bad.
(12:05:08 PM) ogasawara: We can always mark a bug as a duplicate of another bug later on.
(12:05:24 PM) ogasawara: If someone does have the same bug but has nothing additional to add other than a "me too", please don't post a "me too" comment.
(12:05:35 PM) ogasawara: Launchpad now has an +affectsmetoo functionality.  Just click on the "change" link next to "This bug doesn't affect me" under a bug's title.
(12:05:52 PM) ogasawara: Also, be sure to subscribe to the bug to get notifications of any updates made to the bug.
(12:06:03 PM) ogasawara: To subscribe to a bug, click on the "Subscribe/Unsubscribe" link on the right hand side of the bug report.
(12:06:15 PM) ogasawara: For the bug's description, it's always great to include steps to reproduce the issue if possible.
(12:06:39 PM) ogasawara: This helps others to confirm they do indeed have the same bug.
(12:06:47 PM) ogasawara: Additionally, it will help the developers debug the situation by either being able to reproduce the issue or get an idea what might be the root cause of the issue.
(12:07:03 PM) ogasawara: Also, in the bug description it's great to mention if this is a regression or not.
(12:07:14 PM) ogasawara: Specifically noting the most recent version of the kernel where the bug did not occur and the version where the bug was first introduced is helpful.
(12:07:26 PM) ogasawara: This can help isolate the set of kernel patches which should be examined.
(12:07:35 PM) ogasawara: With this version information a git bisect could also be used to determine the specific patch which introduced the regression.
(12:07:53 PM) ogasawara: If a bug reporter is able to perform a git bisect, it's extremely helpful to the kernel team and very much appreciated.
(12:08:04 PM) ogasawara: For those of you who don't know, git is the revision control system which is used by the upstream kernel as well as the Ubuntu kernel.  For more information on git refer to:
(12:08:14 PM) ogasawara: http://www.kernel.org/pub/software/scm/git/docs/
(12:08:22 PM) ogasawara: Regarding the git bisect, it's basically a multi-step process to systematically narrow down a specific commit which introduced a regression.
(12:08:32 PM) ogasawara: It involves a series of steps of marking a known "good" and "bad" kernel version and proceeding to build and test kernels.  It usually only takes a few iterations to narrow down a specific patch which is causing issues.
(12:08:48 PM) ogasawara: For more information please refer to:
(12:08:48 PM) ogasawara: http://www.kernel.org/doc/local/git-quick.html#bisect
(12:09:02 PM) ogasawara: As a general rule of thumb, along with a good bug title and description, kernel bug reports should at a minimum include the following information:
(12:09:12 PM) ogasawara:  * cat /proc/version_signature > version.log
(12:09:12 PM) ogasawara:  * dmesg > dmesg.log
(12:09:12 PM) ogasawara:  * sudo lspci -vvnn > lspci-vvnn.log
(12:09:22 PM) ogasawara: /proc/version_signature lets us know the exact kernel version the bug is against.  It also helps us know that the most recent kernel available is being used.
(12:09:34 PM) ogasawara: dmesg provides a log of kernel messages that often contain helpful debugging information for the kernel team.
(12:09:48 PM) ogasawara: sudo lspci -vvnn lets us know about a system's hardware.
(12:10:00 PM) ogasawara: When providing the above information, please be sure to *attach* each text file *separately*.
(12:10:13 PM) ogasawara: Do not tar up the files, do not zip the files, do not paste the output directly as a comment.
(12:10:33 PM) ogasawara: When developers are looking at numerous bugs each day this can get annoying having to untar files, unzip files, or expand comments to view debug output.
(12:10:52 PM) ogasawara: Also, please please please follow directions when they're given.  If someone asks for the output of 'sudo lspci -vvnn' don't give the output of 'sudo lspci -vv'.
(12:11:07 PM) ogasawara: I know it's silly that I have to specifically point this out, but it's amazing how many people fail to post the requested information or fail to report any information at all even when asked.
(12:11:21 PM) ogasawara: I do understand that sometimes there are language barriers involved, but for the most part using english is a non issue.
(12:11:34 PM) ogasawara: Some additional tips to also help the kernel team is to make sure bug reports are kept up to date.  Even a small comment that the issue still exists against the latest 2.6.xx-yy.zz kernel is useful.
(12:11:50 PM) ogasawara: Also, when asked to test the latest development kernel, please don't be difficult and reply with "I can't believe you want me to test a newer kernel!  This bug is against Hardy, which is an LTS release so it should be fixed there!"
(12:12:10 PM) ogasawara: We understand where the frustration is coming from, but the hostile remark does not help solve the bug.
(12:12:28 PM) ogasawara: The fact of the matter is that before any kernel bug can qualify for a Stable Release Update, the bug must be confirmed as fixed in the actively developed kernel.
(12:12:41 PM) ogasawara: Refer to http://wiki.ubuntu.com/StableReleaseUpdates for the Stable Release Update bug criteria and procedures.
(12:12:56 PM) ogasawara: Also, if a bug has been resolved, don't be afraid to close the bug report.  Marking the bug "Fix Released" helps make the kernel team's (and bug control team's) triaging efforts one step easier.
(12:13:11 PM) ogasawara: We can always use additional help triaging kernel bugs.
(12:13:20 PM) ogasawara: The volume of kernel bugs can be daunting.  Especially considering the limited number of resources the kernel team has.
(12:13:30 PM) ogasawara: The following wiki's are good starting places for those looking to get involved.
(12:13:37 PM) ogasawara: https://wiki.ubuntu.com/KernelTeamBugPolicies
(12:13:37 PM) ogasawara: https://wiki.ubuntu.com/DebuggingProcedures#Kernel
(12:13:45 PM) ogasawara: The first link describes the general kernel team bug policy and the second link is a series of docs for help with debugging specific kernel issues.
(12:13:59 PM) ogasawara: Ok, lets stop and field any questions you may have so far (remember to post them in #ubuntu-classroom-chat - I'll copy and reply to them here).
(12:14:14 PM) ogasawara: just give me a sec to scroll back in #ubuntu-classroom-chat
(12:14:37 PM) ogasawara: <bhk_f> ogasawara: QUESTION: what to do about Greg-K-H's bitching about not enuff patches from someone@canonical
(12:15:29 PM) ogasawara: bhk_f: all I can say is with the limited number of kernel devs we have we do our best to make sure our patches go upstream
(12:16:21 PM) ogasawara: bhk_f: the kernel team is growing in numbers so we'll hopefully be able to contribute more in the future
(12:16:46 PM) ogasawara: drunkenkilla> ogasawara: Question: some notebooks have problems with the brightness for example the samsung and sony notebooks. i created a bug report but nothin happened. is this problem combined with the kernel or is it a driver problem of samsung...?
(12:17:15 PM) ogasawara: drunkenkilla: I'd have to take a look at the bug report, if you can ping me with the bug # in #ubuntu-bugs I'll be sure to take a look
(12:17:33 PM) ogasawara: kippy> QUESTION: how do we know that a bug is for the kernel and not some other package?
(12:17:51 PM) ogasawara: kippy: some common kernel bugs would be, kernel oops or panics
(12:17:59 PM) ogasawara: kippy: complete system lock ups
(12:18:21 PM) ogasawara: kippy: issues with suspend/resume or wifi would also typically be kernel related
(12:18:33 PM) ogasawara: kippy: if in doubt, don't be afraid to ask in #ubuntu-bugs
(12:18:44 PM) ogasawara: lord> QUESTION: what is the reason of kernel renaming?
(12:18:58 PM) ogasawara: lord: basically to make things easier on the kernel team
(12:19:31 PM) ogasawara: lord: having to track one package vs multiple packages is simpler
(12:20:01 PM) ogasawara: lord: additionally it made it difficult to make sure bugs were carried forward when using the old naming convention
(12:20:09 PM) ogasawara: Picklesworth> QUESTION: Is sorting out bug reports one of the reasons for the Ubuntu Hardware Database?
(12:20:21 PM) ogasawara: Picklesworth: yes :)
(12:20:42 PM) ogasawara: mbt> QUESTION:  Is there a way to give a "heads up" when the upstream kernel has a bug in it that needs to be worked around at the Ubuntu level so that we don't have something like the CD/DVD drive regression happen again and slip through a release?
(12:21:14 PM) ogasawara: mbt: best way would be to open a Launchpad bug report but also notify myself and the kernel team in #ubuntu-kernel
(12:21:35 PM) ogasawara: <angusthefuzz> ogasawara: QUESTION: How important are "tags" for kernel bugs?
(12:21:58 PM) ogasawara: angusthefuzz: tags are very helpful with respect to kernel bugs
(12:22:14 PM) ogasawara: angusthefuzz: I used them when we did the 2.6.27 kernel move to note any specific regressions
(12:22:34 PM) ogasawara: angusthefuzz: there are also things like tagging bugs as bitesize for the simpler low hanging bugs that can be quickly resolved
(12:23:07 PM) ogasawara: angusthefuzz:  we've even discussed tagging bugs with the driver being used
(12:23:45 PM) ogasawara: angusthefuzz: I myself use the tags to search bugs in launchpad and I know the kernel team does as well
(12:24:06 PM) ogasawara: angusthefuzz> ogasawara: Are those three required files enough to mark a bug confirmed in most cases?
(12:24:54 PM) ogasawara: angusthefuzz: typically yes.
(12:25:39 PM) ogasawara: angusthefuzz: there are some exceptions, but in general those files should be present to mark a bug confirmed/triaged
(12:26:08 PM) ogasawara: <Tina_Russell> QUESTION: What are some good ways to know if a bug is kernel-related or not?
(12:26:13 PM) ogasawara: Tina_Russell: see answer above
(12:26:28 PM) ogasawara: <lord> ogasawara: are you a kernel developer or just a manger? (i want to know ubuntu organization
(12:26:48 PM) ogasawara: lord: I'm actually a member of the QA Team but work closely with the kernel team and primarily focus on the kernel bugs
(12:27:24 PM) ogasawara: <tkoerfer> QUESTION why don't you wrap those information getters to one program and let it run every time the kernel crashes? or at least let the user start a programm to report this bug?
(12:28:08 PM) ogasawara: tkoerfer: I recommend using apport to report your bug
(12:28:41 PM) ogasawara: <bhk_f> ogasawara: also hows ubuntu kernel different from vanilla
(12:29:13 PM) ogasawara: bhk_f: the kernel team tries to refrain from deviating from the upstream kernel as much as possible
(12:29:47 PM) ogasawara: bhk_f: I'll touch on the upstream sync'ing process in a second
(12:30:25 PM) ogasawara: ok, guys, I'll try to get to more of the questions at the end
(12:30:30 PM) ogasawara: let's continue on
(12:31:14 PM) ogasawara: So now what happens after a high quality kernel bug has been filed?  How is the kernel team notified?
(12:31:25 PM) ogasawara: Bug reports which have been confirmed against the actively developed kernel, have provided all the necessary debugging information, and are ready for a kernel developer to immediately begin debugging should have their Status set to "Triaged".
(12:31:43 PM) ogasawara: Along with setting the Status, the Importance of the bug should be set and the bug should also typically be assigned to the "ubuntu-kernel-team".
(12:32:10 PM) ogasawara: https://wiki.ubuntu.com/KernelTeamBugPolicies explains more about this bug policy.
(12:32:16 PM) ogasawara: Now, here's where the fun starts.
(12:32:23 PM) ogasawara: Knowing that the bug exists in the Ubuntu kernel, it's best to try and confirm the bug exists in the upstream kernel as well.
(12:32:34 PM) ogasawara: If the bug is confirmed to also exist in the upstream kernel, we want to be sure to notify the upstream developers about the issue.
(12:32:52 PM) ogasawara: The upstream kernel bug tracker can be found at http://bugzilla.kernel.org
(12:32:56 PM) ogasawara: Be sure to apply the same best practices when submitting bugs upstream.
(12:33:02 PM) ogasawara: A bug watch can also be added to the Launchpad bug report to monitor the upstream bug report.
(12:33:11 PM) ogasawara: To add a bug watch, click on the "Also affects project" link in the Launchpad bug report.  It's located under a bug's task table.
(12:33:24 PM) ogasawara: Then paste the upstream bug link in the "I have the URL for the upstream bug:" text box.
(12:33:33 PM) ogasawara: Click the "Add to Bug Report" button, and the bug watch should be set.
(12:33:41 PM) ogasawara: All subscribers to the bug should receive email notification for any changes in the upstream bug report's status or importance.
(12:33:56 PM) ogasawara: Getting kernel bugs confirmed and reported upstream is definitely an area where improvements can be made.
(12:34:08 PM) ogasawara: Part of these improvements depend upon the Ubuntu kernel team making it easier for bug reporters to test the upstream kernel.
(12:34:19 PM) ogasawara: This is why there are plans for the kernel team to provide an upstream kernel package which will allow bug reporters to easily install and test the upstream kernel.
(12:34:30 PM) jcastro has changed the topic to: Current Session: Reporting and Fixing Kernel Bugs | Welcome to Openweek, questions in #ubuntu-classroom-chat please || Session details here: https://wiki.ubuntu.com/UbuntuOpenWeek
(12:34:30 PM) ogasawara: I think this will greatly help the upstream bug identification process.
(12:34:40 PM) ogasawara: I would anticipate this being available sometime during the Jaunty development cycle.
(12:34:49 PM) ogasawara: However, for the time being bug reporters will still have to compile the upstream kernel from source.
(12:34:57 PM) ogasawara: I know building the upstream kernel may sound like a scary task, but believe me it's actually quite simple.
(12:35:11 PM) ogasawara: The following wiki documents this process:
(12:35:12 PM) ogasawara: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
(12:35:20 PM) ogasawara: Another advantage to testing the upstream kernel is that the bug may in fact already be fixed upstream.  This is the ideal situation.
(12:35:34 PM) ogasawara: If the specific upstream patch to be pulled in can be identified, definitely post that information to the bug report.
(12:35:46 PM) ogasawara: Otherwise, a comment that this issue is resolved in a specific upstream kernel version is still helpful.
(12:36:00 PM) ogasawara: During each development cycle the Ubuntu kernel is rebased with each of the upstream kernel release candidates until the final upstream kernel release is made for a specific version.
(12:36:16 PM) ogasawara: At that point, the Ubuntu kernel usually stops rebasing with the upstream kernel and will then cherrypick any additional patches from upstream into the Ubuntu kernel.
(12:36:28 PM) ogasawara: The patches which are cherrypicked typically represent fixes to resolve kernel bugs that have been reported.
(12:36:39 PM) ogasawara: Patches continue to be cherrypicked until the Ubuntu kernel freeze, which is usually a few weeks prior to the final release.
(12:36:52 PM) ogasawara: Now, how can someone ensure that the upstream patch will indeed get pulled into the Ubuntu kernel prior to the kernel freeze?
(12:37:03 PM) ogasawara: The best approach would be to inquire about the bug on the FreeNode IRC server in the #ubuntu-kernel channel.
(12:37:15 PM) ogasawara: Additionally, feel free to ping me directly about it.  I should be in the #ubuntu-kernel channel as well.
(12:37:25 PM) ogasawara: We'll make sure we track the bug accordingly and can set the bug's milestone to make sure it stays on the radar of the Ubuntu kernel team.
(12:37:40 PM) ogasawara: Now what about the case where a patch for the bug exists but it's neither in the upstream kernel nor the Ubuntu kernel?
(12:37:54 PM) ogasawara: First, confirming that the patch does indeed resolve the bug is important.
(12:38:02 PM) ogasawara: This does require knowing how to apply a patch and compile the kernel.
(12:38:12 PM) ogasawara: I gave a reference for building the upstream kernel earlier.
(12:38:18 PM) ogasawara: Applying a patch is the same whether using the upstream kernel source of the Ubuntu kernel source.
(12:38:30 PM) ogasawara: The patch command is typically of the form:
(12:38:31 PM) ogasawara: patch -p1 < patch_file.txt
(12:38:37 PM) ogasawara: To find out more about the patch utility, refer to the man page.
(12:38:44 PM) ogasawara: If the patch is going to be built and tested using the Ubuntu kernel source, the following document describes the process of how to build the Ubuntu kernel:
(12:38:54 PM) ogasawara: https://help.ubuntu.com/community/Kernel/Compile
(12:39:01 PM) ogasawara: Building the Ubuntu kernel uses a slightly different set of commands than building the upstream kernel.
(12:39:12 PM) ogasawara: This is because the Ubuntu kernel source provides some additional Ubuntu specific scripts to help build the Ubuntu kernel.
(12:39:23 PM) ogasawara: Assuming the testing proves successful and the patch was applied to the Ubuntu kernel, contact the Ubuntu kernel team on the kernel-team mailing list:
(12:39:35 PM) ogasawara: https://lists.ubuntu.com/mailman/listinfo/kernel-team
(12:39:45 PM) ogasawara: The kernel team monitors the traffic to the mailing list quite closely.
(12:39:55 PM) ogasawara: Patches need to be reviewed before being accepted so contacting the kernel team using the mailing list is better than using IRC in this scenario.
(12:40:05 PM) ogasawara: When sending a patch to the mailing list be sure to follow a few simple rules.
(12:40:13 PM) ogasawara: 1) Mention the Launchpad bug report.
(12:40:20 PM) ogasawara: 2) Summarize the issue and why the patch resolves it.
(12:40:26 PM) ogasawara: 3) Comment that the patch has been tested and confirmed to resolve the issue.
(12:40:33 PM) ogasawara: 4) Be sure to note which kernel version the patch was tested with.
(12:40:40 PM) ogasawara: 5) Inline the patch to the email.  Inlining the patch allows for the kernel team to immediately review the patch in the context of the email.  In addition to inlining the patch, I usually also attach it as well.
(12:40:54 PM) ogasawara: 6) If there's no response after a week, feel free to follow up with the email again.
(12:41:04 PM) ogasawara: If the patch gets accepted into the Ubuntu kernel and does not exist upstream, the Ubuntu kernel team will try to push these patches upstream for review and consideration as well.
(12:41:17 PM) ogasawara: It's a lot of extra work for the Ubuntu kernel team to maintain out of tree (ie out of upstream) patches.
(12:41:28 PM) ogasawara: As a result, they try to make sure patches get incorporated into the upstream kernel.
(12:41:35 PM) ogasawara: Getting patches accepted upstream is in everyone's best interest.
(12:41:44 PM) ogasawara: Everyone benefits from the fix being upstream, not just Ubuntu users.
(12:41:51 PM) ogasawara: It also avoids patches accidentally being dropped and a bug reappearing.
(12:42:00 PM) ogasawara: Now what about the final case of a bug being fixed in the current development release of Ubuntu but still existing in a previous Ubuntu release?
(12:42:14 PM) ogasawara: This is where the Stable Release Update policy is taken into consideration.  http://wiki.ubuntu.com/StableReleaseUpdates
(12:42:24 PM) ogasawara: If the bug does qualify for a Stable Release Update, a release nomination for the bug will be opened and approved.
(12:42:34 PM) ogasawara: If the bug does not qualify for a Stable Release Update, the bug's task table will typically reflect that it's been fixed against the actively developed kernel but will not be fixed as an SRU.
(12:42:47 PM) ogasawara: At a minimum, this should be reflected as a comment in the bug.
(12:42:55 PM) ogasawara: Only certain individuals have the ability to approve release nominations.
(12:43:04 PM) ogasawara: Once approved, the Ubuntu kernel team will try to patch the corresponding kernel with the fix and then the kernel will get uploaded into the -proposed Ubuntu repository.
(12:43:16 PM) ogasawara: -proposed is basically a testing bed for any packages containing updates being considered for a Stable Release Update.
(12:43:27 PM) ogasawara: I'd encourage you to attend the "Verifying Stable Update (SRU) bugfixes" open week session later this week for more information and how to help out.
(12:43:43 PM) ogasawara: As I had mentioned before, the Ubuntu kernel team does have a limited number of resources.  So it is unfortunately the case that not all kernel bugs will get fixed during a given release cycle.
(12:43:56 PM) ogasawara: However, by submitting high quality bug reports, it definitely speeds up the process for when the kernel team is able to get to a bug.
(12:44:06 PM) ogasawara: If you're interested in getting involved in either helping triage or fix kernel bugs, don't be shy.
(12:44:16 PM) ogasawara: Just helping out by making sure bugs have the minimal debug information and are confirmed against the current development kernel is a great starting point for those looking to become triagers.
(12:44:28 PM) ogasawara: You'll also likely want to look at becoming a member of the Ubuntu Bug Control team:
(12:44:28 PM) ogasawara: https://launchpad.net/~ubuntu-bugcontrol
(12:44:40 PM) ogasawara: By becoming a member of ubuntu-bugcontrol you are given certain permissions for setting a bug's status - for example being able to set a bug to "Triaged" or "Won't Fix".
(12:44:51 PM) ogasawara: If you are looking to become more involved in the development aspect of the kernel, refer to:
(12:44:58 PM) ogasawara: https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
(12:45:05 PM) ogasawara: Every little bit helps and it is definitely appreciated.
(12:45:25 PM) ogasawara: So I'd like to use the remaining time to answer any further questions.
(12:46:07 PM) ogasawara: just a sec while I get the next question . . .
(12:47:31 PM) ogasawara: mbt> QUESTION:  Sometimes it's useful to use a vanilla kernel to troubleshoot/compare.  The Wiki says use make-kpkg, but it doesn't seem to work.  Currently I just make and make install, because it works without any conflicts.  But can one easily repackage a vanilla kernel?
(12:48:12 PM) ogasawara: mbt: hrm, I'll review the wiki.  but as I mentioned earlier, the ubuntu kernel team is intending to provide a vanilla kernel for those interested in testing
(12:48:35 PM) ogasawara: <gourgi> ogasawara: QUESTION: how many are in the kernelteam? can't more dev be hired?
(12:49:33 PM) ogasawara: gourgi: there was only 5 devs but we've recently hired on 3 more :)  so yes, more are being hired.
(12:50:03 PM) ogasawara: <m4rt1n> QUESTION: there has been a fuss about Akoya Mini and some other netbooks using the ralink 2860 WLAN card. There is a driver available from ralink. as mobile/small devices are on Canonical's roadmap, will there be some efforts to get the driver in the vanilla kernel?
(12:50:38 PM) ogasawara: m4rt1n: it's preferred if the developers of the driver push the driver upstream first and then it get pulled into the Ubuntu kernel
(12:50:56 PM) ogasawara: m4rt1n: vs Ubuntu pulling it and then trying to push it
(12:51:27 PM) ogasawara: <lord> QUESTION: about the 2.6.27 regression (tcp options reordering) and the solution of ubuntu "disabling time stamp" instead of use an old kernel or delaying release: is it the best solution?, how we can trust ubuntu that he doesn't disable any other features of the kernel?
(12:52:12 PM) ogasawara: lord: a fix was pulled into the kernel for that issue and was released  the same day as Intrepid.
(12:52:33 PM) ogasawara: lord: it's really a call and decision made by the release team, and they should be keeping your best interests in mind
(12:53:05 PM) ogasawara: lord: it's best to also take a look at the release notes page to review any known issues for a release
(12:53:22 PM) ogasawara: <bhk_f> QUESTION: Why are there 2 sessions on SQA - one by ogasawara and one by BrianMurray
(12:53:43 PM) ogasawara: bhk_f: this one is definitely kernel specific
(12:54:02 PM) ogasawara: <andresmujica> QUESTION: Any member of kernel team has commit writes in upstream?
(12:54:24 PM) ogasawara: andresmujica: we use the same process of pushing patches upstream as everyone else - ie via the kernel maintainers
(12:54:58 PM) ogasawara: <angusthefuzz> ogasawara: QUESTION: I noticed an open QA position for creating virtualbox testing images, where do you see images fitting into the kernel bug process?
(12:55:32 PM) ogasawara: angusthefuzz: we'll take as much testing of the kernel as possible whether that be on real hw or in a virtual environment
(12:55:43 PM) ogasawara: <cybernoutles> QUESTION : what is the main case of bugs in the kernel , are there repeated bugs that you encounter over and over?
(12:56:01 PM) ogasawara: cybernoutles: there's always suspend/resume issues I see being reported
(12:56:20 PM) ogasawara: cybernoutles: and with Intrepid it seemed there were more issues with wifi as well
(12:56:50 PM) ogasawara: <bhk_f> QUESTION: Why don't you hire Greg-K-H away from Suse(look wat its doing to his hair!), that will stop his bitching about no patches from canonical...surely
(12:57:41 PM) ogasawara: bhk_f: to be fair, Greg-K-H does great work for the kernel no matter who he works for.  hopefully we can do our best to change his opinion of us.  but just buying off a developer is not the right answer :)
(12:58:16 PM) ogasawara: <bhk_f> QUESTION: Hows ubuntu kernel different from Fedora kernel, for example the current intrepid & fedora ones ?
(12:58:48 PM) jcastro: (last question)
(12:58:52 PM) ogasawara: bhk_f: considering we're both using a 2.6.27 based kernel we should be somewhat similar.  I wouldn't be able to tell you the specific differences though, sorry.
(12:59:04 PM) ogasawara: ok and last question:
(12:59:07 PM) ogasawara: <Guest33263> Question: Bug 279186 (kernel x64 oops on boot for dual core atom D945GCLF2) isn't fixed.  Will I see new kernel updates for Intrepid - now that it is released or do I need to install Jaunty in the hope of a fix ?
(12:59:45 PM) ogasawara: Guest33263: Intrepid will see kernel updates via the SRU process, but it wouldn't hurt to test the Jaunty kernel when available.
(01:00:19 PM) ogasawara: ok, thanks everyone!
(01:00:25 PM) jcastro: thanks leann!