Lines Matching full:your
21 In all other cases try your best guess which kernel part might be causing the
41 separately. While writing your report, include all information relevant to the
43 regressions mailing list (regressions@lists.linux.dev) to your report. Also try
63 a slightly different order. That's in your interest, to make sure you notice
70 document and reporting the issue to your vendor instead, unless you are
74 * Perform a rough search for existing reports with your favorite internet
88 * Ensure your system does not enhance its kernels by building additional
90 without your knowledge.
92 * Check if your kernel was 'tainted' when the issue occurred, as the event
111 thoroughly for reports that might match your issue. If you find anything,
121 suspend your efforts for a few days anyway. Whatever version you choose,
123 increase the risk your report will be rejected or ignored.
132 * Optimize your notes: try to find and write the most straightforward way to
133 reproduce your issue. Make sure the end result has all the important
138 * If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
141 * If your problem is a regression, try to narrow down when the issue was
146 for reproducing, the Linux Distribution used, and your notes on how to
164 report your results. Send friendly reminders if things stall. And try to
207 above, but failed to reproduce your issue there; at the same time you want to
259 to claim your rights, use the vendor's support channel instead. When doing
280 document and reporting the issue to your vendor instead, unless you are
305 explain how to do that once it rules out other potential causes for your issue.
310 issue in question. Your chances are quite good if the distributor applied only
331 *Perform a rough search for existing reports with your favorite internet
337 time for everyone involved, especially you as the reporter. So it's in your own
340 tell you to perform a more detailed search once you know where your issue needs
344 Simply search the internet with your favorite search engine first. Afterwards,
348 If you get flooded with results consider telling your search engine to limit
360 In case you find an existing report about your issue, join the discussion, as
371 need to report your issue". The developers that should take care of the issue
394 might want to be aware of; it for example explains how to add your issue to the
397 What qualifies as security issue is left to your judgment. Consider reading
420 * Use proven tools when building your kernel, as bugs in the compiler or the
423 * Ensure your computer components run within their design specifications;
428 * Try to make sure it's not faulty hardware that is causing your issue. Bad
458 Make sure your kernel doesn't get enhanced
461 *Ensure your system does not enhance its kernels by building additional
463 without your knowledge.*
465 The risk your issue report gets ignored or rejected dramatically increases if
466 your kernel gets enhanced in any way. That's why you should remove or disable
472 Note, you might not be aware that your system is using one of these solutions:
475 module not part of the Linux kernel. That why your might need to uninstall the
482 *Check if your kernel was 'tainted' when the issue occurred, as the event
487 be such an error if your kernel is tainted. That's why it's in your interest to
505 If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst
511 point. In that case check your kernel or system log and look for a section
526 2. Your system uses a software that installs its own kernel modules, for
563 happens with other kernel versions. Therefore, it will make your work easier if
590 Check where you need to report your issue
598 It's crucial to send your report to the right people, as the Linux kernel is a
606 file your issue and make it reach the developers that need to know about it.
615 the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that
636 But this approach won't work if your WiFi chip is connected over USB or some
637 other internal bus. In those cases you might want to check your WiFi manager or
647 are unsure which it is: just try your best guess, somebody will help you if you
678 you where to find a subsystem specific bug tracker to file your issue. The
687 Your report later needs to go by mail to those addresses. Additionally, for all
690 lists when sending your issue report by mail later! Maintainers are busy people
717 Don't sent your report to all of them. Send it to the maintainers, which the
737 thoroughly for reports that might match your issue. If you find anything,
755 'site:lists.infradead.org/pipermail/ath10k/' to your search terms, which limits
759 at this point. If your report needs to be filed in a bug tracker, you may want
778 suspend your efforts for a few days anyway. Whatever version you choose,
780 increase the risk your report will be rejected or ignored.*
788 earlier: doing so dramatically increases the risk that your issue report might
869 Please note that you might need to build your own kernel manually later: that's
892 pick up the configuration of your current kernel and then tries to adjust it
893 somewhat for your system. That does not make the resulting kernel any better,
897 please try to enable CONFIG_KALLSYMS when configuring your kernel.
902 you later to pinpoint the exact line of code that triggers your issue. The
933 line and abandoning your plan to report the issue. But keep in mind that other
944 *Optimize your notes: try to find and write the most straightforward way to
945 reproduce your issue. Make sure the end result has all the important
950 An unnecessarily complex report will make it hard for others to understand your
963 *If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
970 your kernel. If you did so, consider to decode the information from the
982 might need to get from the Linux sources if your distro does not package it)
1011 needed in your case, developers will tell you what to do.
1017 *If your problem is a regression, try to narrow down when the issue was
1050 interpret, which might render your testing useless. Once you found the major
1073 for reproducing, the Linux Distribution used, and your notes on how to
1087 Now that you have prepared everything it's time to write your report. How to do
1092 There is one thing that fits both categories: the most crucial parts of your
1096 better the top section of your report, the higher are the chances that someone
1103 Describe in detail how your issue happens with the fresh vanilla kernel you
1125 that read your report:
1127 * the configuration used for building your Linux kernel (the '.config' file)
1138 your report. If you are filing the issue in a bug tracker then attach them to
1142 * Upload the files somewhere public (your website, a public file paste
1144 <https://bugzilla.kernel.org/>`_, ...) and include a link to them in your
1148 changed just to fix your issue.
1151 replies to your own mail. Just remember to actually do that once the report
1164 * If the issue might be related to your computer hardware, mention what kind
1165 of system you use. If you for example have problems with your graphics card,
1179 libdrm and Mesa; also specify your Wayland compositor or the X-Server and
1194 Those examples should give your some ideas of what data might be wise to
1201 The important part: the head of your report
1217 most important parts of your report: a lot of people will only read this before
1236 introduced the regression as the second part of your subject. Make the report
1238 make your report mention the latest tested version that's working fine (say 5.7)
1252 **Security issues**: for these issues your will have to evaluate if a
1263 offer a way to keep reports private, forget about it and send your report as
1266 In both cases make sure to also mail your report to the addresses the
1282 report your results. Send friendly reminders if things stall. And try to
1285 If your report was good and you are really lucky then one of the developers
1306 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1307 on your mail with the report. This approach will make sure the public mailing
1328 to find the answer own your own by searching the internet; alternatively
1332 **Be patient**: If you are really lucky you might get a reply to your report
1349 regression or not. In such cases raise your concerns on the mailing list and
1359 mail you sent as reply to your report (make sure it has all those in the CC
1360 that up to that point participated in the discussion). This will show your
1364 idea, but only report your results if something relevant changed or if you are
1373 Here are your duties in case you got replies to your report:
1376 developer of the particular code area that will respond to your report. But as
1381 interacting with. By doing this you also get aware if your report was heard by
1409 your report arrived or had something more important to take care of. When
1410 writing the reminder, kindly ask if anything else from your side is needed to
1412 first lines of a mail that is a reply to your initial mail (see above) which
1419 proper reaction, you first should reconsider your approach. Did you maybe try
1457 together that mentions how many you are and why this is something that in your
1547 your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
1556 Once your report is out your might get asked to do a proper one, as it allows to
1570 reproduce your issue with a mainline kernel, but want to see it fixed in older
1589 version line your care about. In that case you'll have no other choice then to
1591 patch the fix into your kernels yourself.
1643 again for discussions about the issue. Search the net with your favorite
1751 linux-doc@vger.kernel.org and "sign-off" your contribution as
1753 your work - the Developer's Certificate of Origin".