Mel Gorman wrote on 28.11.2012 11:13:
> On Tue, Nov 27, 2012 at 03:19:38PM -0800, Linus Torvalds wrote:
>> On Tue, Nov 27, 2012 at 2:26 PM, Johannes Weiner wrote:
>> > On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
>
>> And the one who comes out gets to explain to me which patch(es)
Mel Gorman wrote on 29.11.2012 00:54:
> On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
>> On Wed, 28 Nov 2012 10:13:59 +
>> Mel Gorman wrote:
>>
>> > Based on the reports I've seen I expect the following to work for 3.7
>> > Keep
>> > 96710098 mm: revert "mm: vmscan: scale n
On 30.10.2012 20:18, Mel Gorman wrote:
On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed
Hi!
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
> [...]
diff --git a/m
Johannes Weiner wrote on 29.11.2012 18:05:
> On Thu, Nov 29, 2012 at 04:30:12PM +0100, Thorsten Leemhuis wrote:
>> Mel Gorman wrote on 29.11.2012 00:54:
>> > On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
>> >> On Wed, 28 Nov 2012 10:13:59
Hi!
Johannes Weiner wrote on 01.12.2012 01:45:
> On Fri, Nov 30, 2012 at 01:39:03PM +0100, Thorsten Leemhuis wrote:
>> /me wonders how to elegantly get out of his man-in-the-middle position
> You control the mighty koji :-)
Something even a journalist can ;-)
> But seriousl
Hi!
Just a quick update
Johannes Weiner wrote on 03.12.2012 20:42:
> On Mon, Dec 03, 2012 at 09:30:12AM +0100, Thorsten Leemhuis wrote:
>
>> BTW, I built that kernel without the patch you mentioned in
>> http://thread.gmane.org/gmane.linux.kernel.mm/90911/focus=91153
>> (
On 20.11.2012 16:38, Josh Boyer wrote:
On Fri, Nov 16, 2012 at 3:06 PM, Mel Gorman wrote:
On Fri, Nov 16, 2012 at 02:14:47PM -0500, Josh Boyer wrote:
On Mon, Nov 12, 2012 at 6:37 AM, Mel Gorman wrote:
With "mm: vmscan: scale number of pages reclaimed by reclaim/compaction
based on failures"
Thorsten Leemhuis wrote on 20.11.2012 18:43:
> On 20.11.2012 16:38, Josh Boyer wrote:
>
> The short story from my current point of view is:
Quick update, in case anybody is interested:
> * my main machine at home where I initially saw the issue that started
> this thread seem
the later BIOS-versions again as
Intel doesn't provide a Windows-AHCI driver for the basic ICH8.
HTH and clarifies some of your problems.
Cu
knurd
--
Thorsten Leemhuis
c't- Magazin für Computertechnik webhttp://www.heise.de/ct/
Heise Zeitschriften Verlag
On 16.08.2007 07:43, Willy Tarreau wrote:
> I've just released Linux 2.6.20.16. This version catches up with 2.6.21.7.
> I hope to issue newer releases soon with next batches of pending patches.
>
> I'll also be replying to this message with a copy of the patch between
> 2.6.20.15 and 2.6.20.16.
>
On 16.08.2007 08:29, Willy Tarreau wrote:
> On Thu, Aug 16, 2007 at 08:12:07AM +0200, Thorsten Leemhuis wrote:
>> On 16.08.2007 07:43, Willy Tarreau wrote:
>>> I've just released Linux 2.6.20.16. This version catches up with 2.6.21.7.
>>> I hope to issue newer re
On 06.07.2007 21:45, Chr wrote:
> On Friday, 6. July 2007, Gaston, Jason D wrote:
> On the other hand, we can leave it, because of a
>>> "off-by-one error" in ata_piix.c,
> do_pata_set_dmamode, line ~770:
> [...]
>> I quickly tried this patch on an ICH7-R system with an ATA133 Maxtor
On 02.07.2007 16:36, Chr wrote:
> On Monday, 2. July 2007, Thorsten Leemhuis wrote:
>>> but Alan Cox wrote:
>>> http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg07417.html
>>>> Its ich_pata_133 - all the newer chips are.
>> Intel afaik never suppo
Hi! Here is my fifth regression report for Linux 4.8. It lists 15
regressions I'm aware of. 5 of them are new (for many of those
there are patches available to fix the regression); 3 mentioned
in last weeks report got fixed; 1 is going to be removed.
As always: Are you aware of any other regressi
In case anyone wonders if I regret doing regression tracking for Linux
4.7: No, that is not the case. It isn't really fun, but well, I didn't
expect it to be ;-) But FWIW, find below a few thoughts about the whole
regression tracking thing I thought might be good to write down and
share while they
Hi! Here is my seventh regression report for Linux 4.7. It lists 9
regressions I'm currently aware of. 4 of them are new; 2 are stalled
until the reporter provides more feedback.
The report also mentions 3 regressions that were fixed since the last
report. There is also 1 I plan to remove because
Hi! Find below my third regression report for Linux 4.14. It lists 9
regressions I'm currently aware of. Two regressions got fixed since last
weeks report.
As always: Are you aware of any other regressions? Then please let me
know by mail (a simple bounce or forward in my direction is enough!).
Fo
On 24.10.2017 13:31, John Johansen wrote:
> On 10/23/2017 11:39 PM, Thorsten Leemhuis wrote:
>> Lo, your friendly regression tracker here!
>> On 03.10.2017 09:17, John Johansen wrote:
>>> On 10/02/2017 11:48 PM, Vlastimil Babka wrote:
>>>> On 10/03/2017 07:15
Hi! Find below my fourth regression report for Linux 4.14. It lists 6
regressions I'm currently aware of; for most of them fixes are in the
work. 4 regressions got fixed since last weeks report; 1 turned out to
not be a regression.
As always: Are you aware of any other regressions? Then please let
On 12.03.2018 01:42, Linus Torvalds wrote:
> This continue to be pretty normal - this rc is slightly larger than
> rc4 was, but that looks like one of the normal fluctuations
Hi! Find below my fourth regression report for Linux 4.16. It lists 9
regressions I'm currently aware of. 1 was fixed since
On 05.03.2018 00:15, Linus Torvalds wrote:
> Hmm. A reasonably calm week - the biggest change is to the 'kvm-stat'
> tool, not any actual kernel files.
Hi! Find below my third regression report for Linux 4.16. It lists 7
regressions I'm currently aware of. 3 were fixed since last weeks report.
To
Lo! Your friendly Linux regression tracker here ;-)
On 08.03.2018 14:18, Artem Bityutskiy wrote:
> On Thu, 2018-03-08 at 18:53 +0800, Ming Lei wrote:
>> This patchset tries to spread among online CPUs as far as possible, so
>> that we can avoid to allocate too less irq vectors with online CPUs
>>
gs in bugs, oops or
panics messages. Only thing missing then was a table that quickly describes the
various bits and the taint flags before going into more detail, so I added that
as well.
Signed-off-by: Thorsten Leemhuis
---
Documentation/admin-guide/tainted-kernels.rst | 105 --
1
this small the
simple table format seems way easier to parse when reading the plain text file.
Any feedback much appreciated.
Ciao, Thorsten
Thorsten Leemhuis (1):
docs: Revamp tainted-kernels.rst to make it more comprehensible
Documentation/admin-guide/tainted-kernels.rst | 105 +++
Hi Dave (assuming you are still behind postmas...@vger.kernel.org these
days)!
What do you need from me to create the mailing list
linux-regressi...@vger.kernel.org, to create a dedicated place for CCing
regression reports and discussing regression tracking as whole? Creating
such a list was one o
os will actually ship it in their packages that
contain tools from that directory.
Ciao, Thorsten
#! /bin/sh
# SPDX-License-Identifier: GPL-2.0
#
# Randy Dunlap , 2018
# Thorsten Leemhuis , 2018
usage()
{
cat <
Call without parameters to decode /proc/sys/kernel/tainted.
Call with a posit
Am 20.12.18 um 17:38 schrieb Randy Dunlap:
> On 12/20/18 7:28 AM, Jonathan Corbet wrote:
>> On Thu, 20 Dec 2018 16:23:38 +0100
>> Thorsten Leemhuis wrote:
>>
>>> While at it: Jonathan, you mentioned putting the script in scripts/, but
>>> according to th
Am 20.12.18 um 21:10 schrieb Randy Dunlap:
> On 12/20/18 10:21 AM, Thorsten Leemhuis wrote:
>> Am 20.12.18 um 17:38 schrieb Randy Dunlap:
>>> On 12/20/18 7:28 AM, Jonathan Corbet wrote:
>>>> On Thu, 20 Dec 2018 16:23:38 +0100
>>>> Thorsten Leemhui
Hi! Am 17.12.18 um 19:24 schrieb Jonathan Corbet:
> On Mon, 17 Dec 2018 16:20:42 +0100
> Thorsten Leemhuis wrote:
>
>> +might be relevant later when investigating problems. Don't worry
>> +yourself too much about this, most of the time it's not a problem to run
&
Am 03.01.19 um 19:12 schrieb Jonathan Corbet:
> On Fri, 21 Dec 2018 16:26:31 +0100
> Thorsten Leemhuis wrote:
>>> Here's an idea if you feel like improving this: rather than putting an
>>> inscrutable program inline, add a taint_status script to scripts/ that
>&
Leemhuis:
> Hi! Am 17.12.18 um 19:24 schrieb Jonathan Corbet:
>> On Mon, 17 Dec 2018 16:20:42 +0100
>> Thorsten Leemhuis wrote:
>>
>>> +might be relevant later when investigating problems. Don't worry
>>> +yourself too much about this, most of the time it
Hi kernel.org helpdesk!
Could you please create the email alias
do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
just like sta...@kernel.org does?
That's an idea GregKH brought up a few days ago here:
https://lore.kernel.org/all/2024041123-earthling-primarily-4656@gregkh/
On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>>
>> Could you please create the email alias
>> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
>> just like sta...@kernel.org
On 17.04.24 15:38, Greg KH wrote:
> On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
>> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
>>> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>>>> Could you please create the email
[CCing Sasha]
On 18.04.24 15:20, Greg KH wrote:
> On Thu, Apr 18, 2024 at 09:04:53AM +0200, Thorsten Leemhuis wrote:
>> On 17.04.24 15:38, Greg KH wrote:
>>> On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
>>>> On 17.04.24 14:52, Konstantin Ryabits
On 23.04.24 00:15, Mauro Carvalho Chehab wrote:
>> sta...@kernel.org is there to route to /dev/null on purpose so that
>> developers/maintainers who only want their patches to get picked up when
>> they hit Linus's tree, will have happen and not notify anyone else.
>> This is especially good whe
On 11.06.24 10:42, Vlastimil Babka wrote:
> On 6/11/24 8:23 AM, Greg KH wrote:
>> On Mon, Jun 10, 2024 at 11:40:54PM +0200, Vlastimil Babka wrote:
>>> On 6/10/24 10:36 PM, Steven Rostedt wrote:
On Mon, 10 Jun 2024 08:46:42 -0700
"Paul E. McKenney" wrote:
>>> index 7c29f4afc23d..
[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to
On 30.11.22 11:30, Thorsten Leemhuis wrote:
> [Note: this mail is primarily send for documentation purposes and/or for
> regzbot, my Linux kernel regression tracking bot. That's why I removed
> most or all folks from the list of recipients, but left any that looked
> like a mai
On 11.09.23 16:00, Bagas Sanjaya wrote:
> On 07/09/2023 20:56, Marcus Seyfarth wrote:
>> As to bisecting: Unfortunately I cannot afford the time right now to bisect
>> this further as the system is used in production and already did invest a
>> lot of time without success into it. Hopefully someo
Provide a much shorter and easier process for users that deal with
regressions in stable and longterm kernels, as those should be reported
quickly.
Signed-off-by: Thorsten Leemhuis
---
.../admin-guide/reporting-issues.rst | 91 ---
1 file changed, 40 insertions(+), 51
Am 11.02.21 um 18:07 schrieb Randy Dunlap:
> Just a couple of small nits (or one that is repeated):
:-D
> On 2/9/21 9:48 PM, Thorsten Leemhuis wrote:
>>
>> - * If the failure includes a stack dump, like an Oops does, consider
>> decoding
>> - it to find the off
Hi! Many thx for looking into this, much appreciated!
Am 14.02.21 um 17:00 schrieb Qais Yousef:
> On 02/10/21 06:48, Thorsten Leemhuis wrote:
>
>> - * If the failure includes a stack dump, like an Oops does, consider
>> decoding
>> - it to find the offending line
later.
Signed-off-by: Thorsten Leemhuis
Reviewed-by: Qais Yousef
---
v1->v2
* Fix typo pointed out by Randy
* include review feedback from Qais and bis Reviewed-by:
v1:
https://lore.kernel.org/lkml/20210210054823.242262-1-li...@leemhuis.info/
---
.../admin-guide/reporting-issues.rst
On 07.04.21 16:56, Greg KH wrote:
> On Wed, Apr 07, 2021 at 12:51:43PM +0200, Thorsten Leemhuis wrote:
>> On 07.04.21 11:56, Greg KH wrote:
>>> On Wed, Apr 07, 2021 at 11:21:55AM +0200, Thorsten Leemhuis wrote:
>>>> Add the newly created regression mailing
On 07.09.2007 12:21, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 10:22:27 +0200,
> Romano Giannetti wrote:
>> Takashi: good news!
>>
>> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
>> index 3557865..496d119 100644
>> --- a/sound/pci/hda/patch_realtek.c
>> +++ b/sound/pci
On 07.09.2007 14:58, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 14:04:01 +0200,
> Thorsten Leemhuis wrote:
>> On 07.09.2007 12:21, Takashi Iwai wrote:
>>> At Fri, 07 Sep 2007 10:22:27 +0200,
>>> Romano Giannetti wrote:
>>>> Takashi: good news!
>>>
On 08.09.2007 01:38, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 21:42:36 +0200,
> Thorsten Leemhuis wrote:
> [...]
>> Sorry, but why?
>> It's just this line afaics...
>> + SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
>> ...whic
On 08.09.2007 19:49, Stefan Richter wrote:
> Thorsten Leemhuis wrote:
>> On 08.09.2007 01:38, Takashi Iwai wrote:
> [backports to -stable]
>>> Linux will suck really if one breaks so-called stable thing easily
>>> without actually testing. For stable stuff, "
On 12.09.2007 20:03, Bernd Petrovitsch wrote:
> On Wed, 2007-09-12 at 10:31 -0700, Dan Stromberg wrote:
>> On Wed, 12 Sep 2007 19:09:26 +0200, Bernd Petrovitsch wrote:
> [...]
>>> Fedora BTW abandoned kernel-source* and they have now a website with a
>>> description
>>> how to produce a configured
Hi Sam!
On 12.09.2007 22:03, Sam Ravnborg wrote:
>> I think the Fedora approach has many benefits -- I always wondered why
>> it never went upstream like a "make install_develstuff" that install all
>> the needed bits to
>> /lib/modules/$(uname -r)/build/
> Last time I saw the patch is was to ug
On 13.09.2007 19:22, Sam Ravnborg wrote:
> On Thu, Sep 13, 2007 at 07:09:18PM +0200, Thorsten Leemhuis wrote:
>> On 12.09.2007 22:03, Sam Ravnborg wrote:
>>>> I think the Fedora approach has many benefits -- I always wondered why
>>>> it never went upstream like
Lo! Just stumbled on this by chance while preparing a updated regression
report:
On 19.03.2018 16:49, Sasha Levin wrote:
> From: Christoph Hellwig
>
> [ Upstream commit 84676c1f21e8ff54befe985f4f14dc1edc10046b ]
TWIMC: That commit (also reported by autosel for 4.14) triggered a
regression in 4.
On 26.03.2018 01:37, Linus Torvalds wrote:
> […] Anyway. Go out and test. And let's hope next week is nice and calm and
> I can release the final 4.16 next Sunday without any extra rc's.
>
>Linus
Hi! Find below my sixth regression report for Linux 4.16. It lists 7
regressions I'm
later.
Signed-off-by: Thorsten Leemhuis
---
Reminder: This is not my area of expertise. Hopefully I didn't write anything
stupid or omitted something people find important. If I did, please let me know,
ideally suggesting what to write; bonus points for people sending text I can
simply include i
4 : mp:0.0040W non-operational enlat:15000 exlat:15000 rrt:4 rrl:4
rwt:4 rwl:4 idle_power:- active_power:-
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Thorsten Leemhuis
---
Once this is out I will post a link to it in
https://bugzilla.kernel.org/show_bug.cgi?id=195039, maybe someone th
Am 11.01.21 um 19:14 schrieb Randy Dunlap:
> On 1/10/21 4:10 AM, Thorsten Leemhuis wrote:
>> * About 66 of those ~200 components will assign bugs to email addresses
>> that look valid, but 125 of them end with @kernel-bugs.osdl.org or
>> @kernel-bugs.kernel.org. Those
Am 12.01.21 um 00:42 schrieb Randy Dunlap:
> On 1/11/21 10:55 AM, Thorsten Leemhuis wrote:
>> Am 11.01.21 um 19:14 schrieb Randy Dunlap:
>>> On 1/10/21 4:10 AM, Thorsten Leemhuis wrote:
>
>>> Andrew Morton takes MM bugs and Cc:s them to linux-mm mailing list
>&
Thx for your reply and sorry for forgetting to CC you; that was the
plan, but I forgot when I called git send-email :-/
Am 11.01.21 um 20:48 wrote Konstantin Ryabitsev:
> On Sun, Jan 10, 2021 at 01:10:33PM +0100, Thorsten Leemhuis wrote:
>> The front page doesn't make this aspect o
ith isn't particular concerning.
* sound/alsa-configuration.rst and sound/hd-audio/notes.rst -- they
mention it as a place to file bugs. Looks like at least some are
looked at, thus leave this as it is for now.
* A few translations still mention the bug tracker; they hopefully
notic
Am 30.12.20 um 16:45 schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Changing some inline functions to use the new irq_check_status_bit
> function out of line breaks calling them from loadable modules:
>
> ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko]
> undefined!
Just
Hi Jonathan!
On 19.03.21 20:27, Thorsten Leemhuis wrote:
> This series bundle a few patches that piled up for
> Documentation/admin-guide/reporting-issues.rst. The main changes are these:
Sorry to bring the following up, as I saw you mentioning in another mail
on linux-doc you have a lot o
On 25.03.21 19:43, Jonathan Corbet wrote:
> Thorsten Leemhuis writes:
>
>> That's why I'd like to speed things up a little. But for that it would
>> be good to have something from you: a kind of "I like the direction
>> where this patch set is heading a
; into two. That has the additinal benefit that users will search
for them quickly when going through the step by step guide and thus will
save them trouble if the find reports.
Signed-off-by: Thorsten Leemhuis
CC: Randy Dunlap
---
v3
* s/head over/scroll down/, as suggested by Jon
* reduce the
eport bugs,
even if they can't test vanilla mainline kernel.
Signed-off-by: Thorsten Leemhuis
CC: Randy Dunlap
---
With this I try to get rid of the last remaining parts that have a
'this needs discussion' box that's in the text. I hope I've found a
middle ground that ever
Reorder some steps where the order in which the readers perform them is
not crucial. This is a preparation for a later change that would make
the text much more complex otherwise.
Content just moved, not changed at all in the process.
Signed-off-by: Thorsten Leemhuis
---
.../admin-guide
rnel.org/linux-doc/cover.1615116592.git.li...@leemhuis.info/
* initial version, starting straight with v2 to avoid confusion, as one of the
patches was submitted earlier already
Thorsten Leemhuis (5):
docs: reporting-issues.rst: fix small typos and style issues
docs: reporting-issues.rst: tone do
Fix a typo and change "head over" to "scroll down", as suggested by Jon
when reviewing another patch that used the phrase the same way.
Signed-off-by: Thorsten Leemhuis
---
Documentation/admin-guide/reporting-issues.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deleti
This duplicates two section to make the diff in the next patch a bit
easier to gasp for humans.
Straight copy, no content changes.
Signed-off-by: Thorsten Leemhuis
---
.../admin-guide/reporting-issues.rst | 184 ++
1 file changed, 184 insertions(+)
diff --git a
On 16.03.21 18:56, Thorsten Leemhuis wrote:
> On 15.03.21 21:20, Jonathan Corbet wrote:
>> Thorsten Leemhuis writes:
>
>> Anything that could be done to
>> make it more concise going forward would be more than welcome.
> Yeah, will think about it, especially WRT to
On 15.03.21 21:11, Jonathan Corbet wrote:
> Thorsten Leemhuis writes:
>
>> Provide a much shorter and easier process for users that deal with
>> regressions in stable and longterm kernels, as those should be reported
>> quickly.
>>
>> Signed-off-by: Th
On 22.03.21 22:56, Theodore Ts'o wrote:
> On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote:
>> I agree to the last point and yeah, maybe regressions are the more
>> important problem we should work on – at least from the perspective of
>> kernel develo
On 23.03.21 19:11, Theodore Ts'o wrote:
> On Tue, Mar 23, 2021 at 09:57:57AM +0100, Thorsten Leemhuis wrote:
>> On 22.03.21 22:56, Theodore Ts'o wrote:
>>> On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote:
>>>> I agree to the last point
On 23.03.21 16:01, Konstantin Ryabitsev wrote:
> On Tue, 23 Mar 2021 at 04:58, Thorsten Leemhuis wrote:
>>> If we can
>>> actually get users to *read* it, I think it's going to save kernel
>>> developers a huge amount of time and frustration.
>> And user
This patchset makes reporting-issues.rst fully official and thus removes
reporting-bugs.rst. It also adds an entry for the text in MAINTAINERS as
discussed earlier. Then there is the new text for the TLDR already posted as a
draft and a patch which assorted fixes and small enhancements.
Thorsten
or another have been around for a long
time. I'm sure over the years you got read a lot and helped quite a few
people. But it's time to retire now. Rest in peace.
Signed-off-by: Thorsten Leemhuis
CC: Harry Wei
CC: Alex Shi
CC: Federico Vaga
CC: Greg KH
---
Removing Documentation/a
matches the step by step guide better.
Signed-off-by: Thorsten Leemhuis
---
v1
- Incorporated feedback received from posting a draft to LKML. Also
slightly change the beginning of the third paragraph to improve the
flow.
---
.../admin-guide/reporting-issues.rst | 75 +--
1
;CC stable maintainers" bits
- fix a few typos and mistakes in the text, with a few very small
improvements along the way
Signed-off-by: Thorsten Leemhuis
---
.../admin-guide/reporting-issues.rst | 79 +++
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git
Thorsten will keep an eye on the new document about reporting issues
(aka bugs).
Signed-off-by: Thorsten Leemhuis
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e66ff3daf23c..b5d38fedff6c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Argh, sent this just one hour ago and I already found the first problem:
On 30.03.21 16:13, Thorsten Leemhuis wrote:
> Make the TLDR a bit shorter while improving it at the same time by going
> straight to the aspects readers are more interested it. The change makes
> the process especi
Lo! I want to provide users with an easier way to search our multitude
of mailing lists for reports about issues (aka bugs), as reporting the
same kernel problem multiple times has known downsides for everyone
involved. That's why I propose to create this new mailing list:
linux-iss...@lists.lin
On 22.03.21 19:34, Eric Wong wrote:
> James Bottomley wrote:
>> On Mon, 2021-03-22 at 13:16 -0400, Konstantin Ryabitsev wrote:
>>> On Mon, Mar 22, 2021 at 04:18:14PM +0100, Thorsten Leemhuis wrote:
>>>> Note, there is a second reason why ksummit-discuss is CCed: ano
On 22.03.21 19:32, Linus Torvalds wrote:
> On Mon, Mar 22, 2021 at 8:18 AM Thorsten Leemhuis wrote:
>>
>> I even requested a
>> "linux-regressi...@vger.kernel.org" a while later, but didn't hear
>> anything back; and, sadly, about the same time
On 22.03.21 17:55, Lukas Bulwahn wrote:
> On Mon, Mar 22, 2021 at 4:38 PM Thorsten Leemhuis wrote:
>> Lo! I want to provide users with an easier way to search our multitude
>> of mailing lists for reports about issues (aka bugs), as reporting the
>> same kernel problem mul
On 15.03.21 21:20, Jonathan Corbet wrote:
> Thorsten Leemhuis writes:
>> Tell users that reporting bugs with vendor kernels which are only
>> slightly patched can be okay in some situations, but point out there's a
>> risk in doing so.
>>
>> Adjust some re
On 30.03.21 07:59, Greg KH wrote:
> On Mon, Mar 29, 2021 at 04:44:21PM -0600, Jonathan Corbet wrote:
>> Thorsten Leemhuis writes:
>>
>>> FWIW, on another channel someone mentioned the process in the TLDR is
>>> quite complicated when it comes to regressions in s
Lo! Since a few months mainline in
Documentation/admin-guide/reporting-issues.rst contains a text written
to obsolete the good old reporting-bugs text. For now, the new document
still contains a warning at the top that basically says "this is WIP".
But I'd like to remove that warning and delete r
On 26.03.21 07:13, Thorsten Leemhuis wrote:
>
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basicall
On 26.03.21 07:13, Thorsten Leemhuis wrote:
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says
On 26.03.21 07:13, Thorsten Leemhuis wrote:
>
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basicall
On 26.03.21 07:13, Thorsten Leemhuis wrote:
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says
On 26.03.21 07:13, Thorsten Leemhuis wrote:
>
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basicall
On 26.03.21 07:23, Guenter Roeck wrote:
> On 3/25/21 11:15 PM, Thorsten Leemhuis wrote:
>> On 26.03.21 07:13, Thorsten Leemhuis wrote:
>
>> mention if backporting is planed or considered too complex. If backporting
>> was
> planned
ha, of course, thx for pointing it out! Ciao, Thorsten
On 26.03.21 09:59, Greg KH wrote:
> On Fri, Mar 26, 2021 at 07:13:09AM +0100, Thorsten Leemhuis wrote:
>>
>> Lo! Since a few months mainline in
>> Documentation/admin-guide/reporting-issues.rst contains a text written
>> to obsolete the good old reporting-bugs text
On 26.03.21 07:15, Thorsten Leemhuis wrote:
> On 26.03.21 07:13, Thorsten Leemhuis wrote:
>>
>> Lo! Since a few months mainline in
>> Documentation/admin-guide/reporting-issues.rst contains a text written
>> to obsolete the good old reporting-bugs text. For now, the new
made a difference.
Link:
https://lore.kernel.org/lkml/dff6badf-58f5-98c8-871c-94d901ac6...@leemhuis.info/
Link:
https://lore.kernel.org/lkml/cajz5v0hx2stqvttacihyh-uruh+hi92z9z2zbcngqpt0e2j...@mail.gmail.com/
Signed-off-by: Thorsten Leemhuis
---
.../admin-guide/reporting-issues.rst
On 14.04.21 15:42, Rafael J. Wysocki wrote:
> On Wed, Apr 14, 2021 at 3:22 PM w4v3 wrote:
>>> Links to your bug report and the thread on the mailing list would have
>>> helped here to understand better what's going on, but whatever, they are
>>> not that important.
>> Here you go: https://bugzilla
[CCing Rafael]
Beforehand: many thx for your feedback and for reporting the bug you
faced, much appreciated.
On 13.04.21 23:18, w4v3 wrote:
> I would like to make some suggestions regarding the "Reporting
> issues" document
> (https://www.kernel.org/doc/html/latest/admin-guide/reporting-issue
On 07.04.21 10:20, Mauro Carvalho Chehab wrote:
> Changeset d2ce285378b0 ("docs: make reporting-issues.rst official and delete
> reporting-bugs.rst")
> dropped reporting-bugs.rst, in favor of reporting-issues.rst, but
> translations still need to be updated, in order to point to the
> new file.
>
1 - 100 of 343 matches
Mail list logo
