Lines Matching full:your
30 In all other cases try your best guess which kernel part might be causing the
50 separately. While writing your report, include all information relevant to the
52 regressions mailing list (regressions@lists.linux.dev) to your report. Also try
72 a slightly different order. That's in your interest, to make sure you notice
79 document and reporting the issue to your vendor instead, unless you are
83 * Perform a rough search for existing reports with your favorite internet
97 * Ensure your system does not enhance its kernels by building additional
99 without your knowledge.
101 * Check if your kernel was 'tainted' when the issue occurred, as the event
120 thoroughly for reports that might match your issue. If you find anything,
130 suspend your efforts for a few days anyway. Whatever version you choose,
132 increase the risk your report will be rejected or ignored.
141 * Optimize your notes: try to find and write the most straightforward way to
142 reproduce your issue. Make sure the end result has all the important
147 * If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
150 * If your problem is a regression, try to narrow down when the issue was
155 for reproducing, the Linux Distribution used, and your notes on how to
173 report your results. Send friendly reminders if things stall. And try to
216 above, but failed to reproduce your issue there; at the same time you want to
268 to claim your rights, use the vendor's support channel instead. When doing
289 document and reporting the issue to your vendor instead, unless you are
314 explain how to do that once it rules out other potential causes for your issue.
319 issue in question. Your chances are quite good if the distributor applied only
340 *Perform a rough search for existing reports with your favorite internet
346 time for everyone involved, especially you as the reporter. So it's in your own
349 tell you to perform a more detailed search once you know where your issue needs
353 Simply search the internet with your favorite search engine first. Afterwards,
357 If you get flooded with results consider telling your search engine to limit
369 In case you find an existing report about your issue, join the discussion, as
380 need to report your issue". The developers that should take care of the issue
412 What qualifies as security issue is left to your judgment. Consider reading
435 * Use proven tools when building your kernel, as bugs in the compiler or the
438 * Ensure your computer components run within their design specifications;
443 * Try to make sure it's not faulty hardware that is causing your issue. Bad
473 Make sure your kernel doesn't get enhanced
476 *Ensure your system does not enhance its kernels by building additional
478 without your knowledge.*
480 The risk your issue report gets ignored or rejected dramatically increases if
481 your kernel gets enhanced in any way. That's why you should remove or disable
487 Note, you might not be aware that your system is using one of these solutions:
490 module not part of the Linux kernel. That why your might need to uninstall the
497 *Check if your kernel was 'tainted' when the issue occurred, as the event
502 be such an error if your kernel is tainted. That's why it's in your interest to
520 If your kernel is tainted, study 'Documentation/admin-guide/tainted-kernels.rst'
526 point. In that case check your kernel or system log and look for a section
541 2. Your system uses a software that installs its own kernel modules, for
578 happens with other kernel versions. Therefore, it will make your work easier if
605 Check where you need to report your issue
613 It's crucial to send your report to the right people, as the Linux kernel is a
621 file your issue and make it reach the developers that need to know about it.
630 the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that
651 But this approach won't work if your WiFi chip is connected over USB or some
652 other internal bus. In those cases you might want to check your WiFi manager or
662 are unsure which it is: just try your best guess, somebody will help you if you
693 you where to find a subsystem specific bug tracker to file your issue. The
702 Your report later needs to go by mail to those addresses. Additionally, for all
705 lists when sending your issue report by mail later! Maintainers are busy people
732 Don't sent your report to all of them. Send it to the maintainers, which the
752 thoroughly for reports that might match your issue. If you find anything,
770 'site:lists.infradead.org/pipermail/ath10k/' to your search terms, which limits
774 at this point. If your report needs to be filed in a bug tracker, you may want
793 suspend your efforts for a few days anyway. Whatever version you choose,
795 increase the risk your report will be rejected or ignored.*
803 earlier: doing so dramatically increases the risk that your issue report might
884 Please note that you might need to build your own kernel manually later: that's
907 pick up the configuration of your current kernel and then tries to adjust it
908 somewhat for your system. That does not make the resulting kernel any better,
912 please try to enable CONFIG_KALLSYMS when configuring your kernel.
917 you later to pinpoint the exact line of code that triggers your issue. The
948 line and abandoning your plan to report the issue. But keep in mind that other
959 *Optimize your notes: try to find and write the most straightforward way to
960 reproduce your issue. Make sure the end result has all the important
965 An unnecessarily complex report will make it hard for others to understand your
978 *If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
985 your kernel. If you did so, consider to decode the information from the
997 might need to get from the Linux sources if your distro does not package it)
1026 needed in your case, developers will tell you what to do.
1032 *If your problem is a regression, try to narrow down when the issue was
1065 interpret, which might render your testing useless. Once you found the major
1087 for reproducing, the Linux Distribution used, and your notes on how to
1101 Now that you have prepared everything it's time to write your report. How to do
1106 There is one thing that fits both categories: the most crucial parts of your
1110 better the top section of your report, the higher are the chances that someone
1117 Describe in detail how your issue happens with the fresh vanilla kernel you
1139 that read your report:
1141 * the configuration used for building your Linux kernel (the '.config' file)
1152 your report. If you are filing the issue in a bug tracker then attach them to
1156 * Upload the files somewhere public (your website, a public file paste
1158 <https://bugzilla.kernel.org/>`_, ...) and include a link to them in your
1162 changed just to fix your issue.
1165 replies to your own mail. Just remember to actually do that once the report
1178 * If the issue might be related to your computer hardware, mention what kind
1179 of system you use. If you for example have problems with your graphics card,
1193 libdrm and Mesa; also specify your Wayland compositor or the X-Server and
1208 Those examples should give your some ideas of what data might be wise to
1215 The important part: the head of your report
1231 most important parts of your report: a lot of people will only read this before
1250 introduced the regression as the second part of your subject. Make the report
1252 make your report mention the latest tested version that's working fine (say 5.7)
1266 **Security issues**: for these issues your will have to evaluate if a
1277 offer a way to keep reports private, forget about it and send your report as
1280 In both cases make sure to also mail your report to the addresses the
1296 report your results. Send friendly reminders if things stall. And try to
1299 If your report was good and you are really lucky then one of the developers
1320 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1321 on your mail with the report. This approach will make sure the public mailing
1342 to find the answer own your own by searching the internet; alternatively
1346 **Be patient**: If you are really lucky you might get a reply to your report
1363 regression or not. In such cases raise your concerns on the mailing list and
1373 mail you sent as reply to your report (make sure it has all those in the CC
1374 that up to that point participated in the discussion). This will show your
1378 idea, but only report your results if something relevant changed or if you are
1387 Here are your duties in case you got replies to your report:
1390 developer of the particular code area that will respond to your report. But as
1395 interacting with. By doing this you also get aware if your report was heard by
1423 your report arrived or had something more important to take care of. When
1424 writing the reminder, kindly ask if anything else from your side is needed to
1426 first lines of a mail that is a reply to your initial mail (see above) which
1433 proper reaction, you first should reconsider your approach. Did you maybe try
1471 together that mentions how many you are and why this is something that in your
1561 your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
1570 Once your report is out your might get asked to do a proper one, as it allows to
1584 reproduce your issue with a mainline kernel, but want to see it fixed in older
1603 version line your care about. In that case you'll have no other choice then to
1605 patch the fix into your kernels yourself.
1657 again for discussions about the issue. Search the net with your favorite
1763 linux-doc@vger.kernel.org and "sign-off" your contribution as
1765 your work - the Developer's Certificate of Origin".