disabled CONFIG_FORCE_NR_CPUS option for 6.9.5 but the trace + panic
still exists. So that one didn't help. I've also been bisecting the
trace but have not finished it yet as the last half dozen builds
produced non-bootable kernels. Anyway, I will continue it soon(ish)
when I have a bit more free
On Thu, 13 Jun 2024 10:32:24 +0300
Ilkka Naulapää wrote:
> ok, so if you don't have any idea where this bug is after those debug
> patches, I'll try to find some time to bisect it as a last resort.
> Stay tuned.
FYI,
I just debugged a strange crash that was caused by my config having
something
On 13.06.24 09:32, Ilkka Naulapää wrote:
> On Wed, Jun 12, 2024 at 6:56 PM Steven Rostedt wrote:
>> On Wed, 12 Jun 2024 15:36:22 +0200
>> "Linux regression tracking (Thorsten Leemhuis)"
>> wrote:
>>>
>>> Ilkka or Steven, what happened to this? This thread looks stalled. I
>>> also was unsuccessf
ok, so if you don't have any idea where this bug is after those debug
patches, I'll try to find some time to bisect it as a last resort.
Stay tuned.
--Ilkka
On Wed, Jun 12, 2024 at 6:56 PM Steven Rostedt wrote:
>
> On Wed, 12 Jun 2024 15:36:22 +0200
> "Linux regression tracking (Thorsten Leemhui
On Wed, 12 Jun 2024 15:36:22 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
>
> Ilkka or Steven, what happened to this? This thread looks stalled. I
> al
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Ilkka or Steven, what happened to this? This thread looks stalled. I
also was unsuccessful when looking for other threads related to this
report or the culprit. Did it fall t
On Thu, 30 May 2024 16:02:37 +0300
Ilkka Naulapää wrote:
> applied your patch and here's the output.
>
Unfortunately, it doesn't give me any new information. I added one more
BUG on, want to try this? Otherwise, I'm pretty much at a lost. :-/
-- Steve
diff --git a/fs/tracefs/inode.c b/fs/trac
On Wed, 29 May 2024 14:47:57 -0400
Steven Rostedt wrote:
> Let me make a debug patch (that crashes on this issue) for that kernel,
> and perhaps you could bisect it?
Can you try this on 6.6-rc1 and see if it gives you any other splats?
Hmm, you can switch it to WARN_ON and that way it may not c
On Wed, 29 May 2024 21:36:08 +0300
Ilkka Naulapää wrote:
> applied your patch without others, so trace and panic there.
> Screenshot attached. Also tested kernels backward and found out that
Bah, it's still in an RCU callback, which doesn't tell us why a
normal inode is being sent to the trace i
On Tue, 28 May 2024 07:51:30 +0300
Ilkka Naulapää wrote:
> yeah, the cache_from_obj tracing bug (without panic) has been
> displayed quite some time now - maybe even since 6.7.x or so. I could
> try checking a few versions back for this and try bisecting it if I
> can find when this started.
>
yeah, the cache_from_obj tracing bug (without panic) has been
displayed quite some time now - maybe even since 6.7.x or so. I could
try checking a few versions back for this and try bisecting it if I
can find when this started.
--Ilkka
On Tue, May 28, 2024 at 1:31 AM Steven Rostedt wrote:
>
> On
I tried 6.10-rc1 and it still ends up to panic
--Ilkka
On Tue, May 28, 2024 at 12:44 AM Steven Rostedt wrote:
>
> On Mon, 27 May 2024 20:14:42 +0200
> Greg KH wrote:
>
> > On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> > > Hi Steven,
> > >
> > > I took some time and bisected
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> > - Affected Versions: Before kernel version 6.8.10, the bug caused a
> > quick display of a kernel trace dump before the shutdown/reboot
> > completed. Starting from version 6.8.10 and continuing into ve
On Mon, 27 May 2024 20:14:42 +0200
Greg KH wrote:
> On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> > Hi Steven,
> >
> > I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
> > panic inducing commit:
> >
> > 414fb08628143 (tracefs: Reset permissions on remount if
On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> Hi Steven,
>
> I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
> panic inducing commit:
>
> 414fb08628143 (tracefs: Reset permissions on remount if permissions are
> options)
>
> I reverted that commit to 6.9.2
Hi Steven,
I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
panic inducing commit:
414fb08628143 (tracefs: Reset permissions on remount if permissions are options)
I reverted that commit to 6.9.2 and now it only serves the trace but
the panic is gone. But I can live with it.
--
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> > - Affected Versions: Before kernel version 6.8.10, the bug caused a
> > quick display of a kernel trace dump before the shutdown/reboot
> > completed. Starting from version 6.8.10 and continuing into ve
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> [CCing a few people]
>
Thanks for the Cc.
> On 24.05.24 12:31, Ilkka Naulapää wrote:
> >
> > I have encountered a critical bug in the Linux vanilla kernel that
> > leads to a kernel panic during the s
[CCing a few people]
On 24.05.24 12:31, Ilkka Naulapää wrote:
>
> I have encountered a critical bug in the Linux vanilla kernel that
> leads to a kernel panic during the shutdown or reboot process. The
> issue arises after all services, including `journald`, have been
> stopped. As a result, the
On 02/28/2007 02:04 PM, Alan wrote:
PLIP/Laplink runs bidirectional on ordinary parallel ports. The
bidirectional part of parallel ports in "normal" modes is still used
for things like PnP detection of printer and drivers.
And my parallel port Iomega ZIP drive, it seems. I actually checked
e
> The bidirectional use is/was PL/IP, aka "laplink" connections. Yes, I
> still have a machine I installed that way, and it will run 2.2.19
> forever before I try it again. ;-)
PLIP/Laplink runs bidirectional on ordinary parallel ports. The
bidirectional part of parallel ports in "normal" modes
Linus Torvalds wrote:
On Mon, 26 Feb 2007, Rene Herman wrote:
Other than these two, ECP parallel ports are the other remaining users.
Now, even though on a machine that still has a parallel port it might usually
indeed be set to ECP in its BIOS; having anything attached to the port also
use it
On Mon, 26 Feb 2007, Rene Herman wrote:
>
> Other than these two, ECP parallel ports are the other remaining users.
> Now, even though on a machine that still has a parallel port it might usually
> indeed be set to ECP in its BIOS; having anything attached to the port also
> use it as such seems
For me, adding the "local_irq_enable();" in default_idle() of
arch/i386/kernel/process.c
make the floppy work again without problem.
Etienne.
___
Découvrez une nouvelle façon d'obteni
On 02/26/2007 07:13 PM, Linus Torvalds wrote:
The floppy is still pretty much the only user of native motherboard
(aka i8237) DMA'ing for most people. Some old ISA sound-cards may do
it, of course.
Other than these two, ECP parallel ports are the other remaining users.
Now, even though on a ma
On Mon, 26 Feb 2007, Oleg Nesterov wrote:
>
> I know nothing about floppy, but I guess the reason is floppy_disable_hlt().
>
> Sorry for the offtopic question, is it really needed? According to grep,
> floppy
> is the only one user of disable_hlt().
I suspect you'd have a hard time finding a
Stephane Eranian wrote:
>
> On Mon, Feb 26, 2007 at 09:10:22AM -0800, Linus Torvalds wrote:
> >
> > It is in fact possible that the floppy failure might just be from some
> > timing-dependent thing, and the slowdown itself is the problem.
> >
> > Although I do find that a bit unlikely, since machin
Linus,
On Mon, Feb 26, 2007 at 09:10:22AM -0800, Linus Torvalds wrote:
> >
> > Side note: this patch adds several function calls (4), several additional
> > L1 cache touches and a generally inefficient code path to *every single
> > interrupt that exits from the idle poll*, not to mention the e
On Mon, 26 Feb 2007, Stephane Eranian wrote:
>
> The same code was used for i386 but I think for both architectures, the patch
> is missing default_idle(). I believe deault idle should look as follows:
Side note - I'll revert it regardless.
We can re-merge it later after
- it has been tested
Hi,
On Mon, Feb 26, 2007 at 07:51:19AM -0800, Linus Torvalds wrote:
>
>
> On Mon, 26 Feb 2007, Jiri Slaby wrote:
> >
> > Ok, this commit is the culprit:
> > Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
> > Author: Stephane Eranian <[EMAIL PROTECTED]> Tue, 13 Feb 2007 13:26:22 +0100
> >
> >
On Mon, 26 Feb 2007, Benjamin LaHaise wrote:
>
> Side note: this patch adds several function calls (4), several additional
> L1 cache touches and a generally inefficient code path to *every single
> interrupt that exits from the idle poll*, not to mention the extra (useless,
> as it doesn't g
On Mon, Feb 26, 2007 at 07:51:19AM -0800, Linus Torvalds wrote:
> > Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
> > Author: Stephane Eranian <[EMAIL PROTECTED]> Tue, 13 Feb 2007 13:26:22 +0100
> >
> > [PATCH] i386: add idle notifier
>
> Interesting. It doesn't touch floppy at all, but it
Linus Torvalds napsal(a):
On Mon, 26 Feb 2007, Jiri Slaby wrote:
Ok, this commit is the culprit:
Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
Author: Stephane Eranian <[EMAIL PROTECTED]> Tue, 13 Feb 2007 13:26:22 +0100
[PATCH] i386: add idle notifier
Interesting. It doesn't touch flo
On Mon, 26 Feb 2007, Jiri Slaby wrote:
>
> Ok, this commit is the culprit:
> Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
> Author: Stephane Eranian <[EMAIL PROTECTED]> Tue, 13 Feb 2007 13:26:22 +0100
>
> [PATCH] i386: add idle notifier
Interesting. It doesn't touch floppy at all, but
Jiri Slaby napsal(a):
Once again and for the last time: I do not state that floppy.c is
broken. I only state that it is immpossible to mount a floppy drive
with kernel 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1
is definitely buggy!
I did some work already:
a. I copied the follow
> a. Can someone please confirm the described problem?
I can confirm that "mdir a:" without a floppy in the driver does not crash.
If there is a floppy, it crashes immediately (do "sync; sync" before to
limit file corruption). Tried with and without tickless, not related (no
change).
If loc
Uwe Bugla napsal(a):
Hi folks,
Hi.
Once again and for the last time: I do not state that floppy.c is broken. I
only state that it is immpossible to mount a floppy drive with kernel
2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely buggy!
I did some work already:
a. I c
On Sun, 2007-02-25 at 19:29 +0100, Uwe Bugla wrote:
> Hi everybody,
> "The bug was introduced somewhere at the transition of 2.6.20 towards
> 2.6.20-git14."
> I fortunately had some git9 patch at home and found out that it is sane.
> In so far the floppy mount bug was introduced somewhen between 2
On Sun, Feb 25, 2007 at 07:29:39PM +0100, Uwe Bugla wrote:
> "The bug was introduced somewhere at the transition of 2.6.20 towards
> 2.6.20-git14."
> I fortunately had some git9 patch at home and found out that it is sane.
> "I'm afraid that the most proactical
> way of fixing this is to ask you t
it is definitely NOT my job to repair errors that other responsibility-free
people pushed into vanilla mainline without the slightest test effort in some
mm-tree for example. Who wasted it must repair it, without the slightest
discussion!
You're assuming the author didn't test it. For things
Original-Nachricht
Datum: Sat, 24 Feb 2007 10:07:29 -0800
Von: Andrew Morton <[EMAIL PROTECTED]>
An: "Uwe Bugla" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org
Betreff: Re: bug in kernel 2.6.21-rc1-git1: con
Original-Nachricht
Datum: Sat, 24 Feb 2007 10:07:29 -0800
Von: Andrew Morton <[EMAIL PROTECTED]>
An: "Uwe Bugla" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org
Betreff: Re: bug in kernel 2.6.21-rc1-git1: con
> On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <[EMAIL PROTECTED]> wrote:
> Hi folks,
> Second attempt now:
> I already reported to Linus Torvalds and Andrew Morton that it is impossible
> to mount a conventional floppy drive without hanging up the whole system.
> Andrew's reaction was quite amb
On Mon, 14 Mar 2005, Evgeniy wrote:
Here is a simple program.
#include
#include
main(){
int err;
err=read(0,NULL,6);
printf("%d %d\n",err,errno);
}
I think that it should be an error : Null pointer assignment, like in windows.
But in practise it is not so.
It is an error. It will wait until y
On Mon, 14 Mar 2005 17:48:05 +0300
Evgeniy <[EMAIL PROTECTED]> bubbled:
> Here is a simple program.
>
> #include
> #include
> main(){
> int err;
> err=read(0,NULL,6);
> printf("%d %d\n",err,errno);
> }
Results:
# ./a < /dev/zero
read(0, 0, 6) = -1 EFAULT (Bad a
I ran the little test program on my 2.4.26 Knoppix system, and got the
following two results:
strace a.out < /dev/tty
...
read(0, NULL, 6)= 1
...
strace a.out < /dev/zero
...
read(0, 0, 6) = -1 EFAULT (Bad address)
...
The first cas
On Monday 14 March 2005 15:48, Evgeniy wrote:
> #include
> #include
> main(){
> int err;
> err=read(0,NULL,6);
> printf("%d %d\n",err,errno);
> }
On my box (2.6.11), that does exactly what it is supposed to do -- "-1 14"
14 == EFAULT == "Bad Address", which is what NULL is...
Btw, printf(
On Mon, 2005-03-14 at 15:51 +0100, Arjan van de Ven wrote:
> On Mon, 2005-03-14 at 17:48 +0300, Evgeniy wrote:
> > Here is a simple program.
> >
> > #include
> > #include
> > main(){
> > int err;
> > err=read(0,NULL,6);
> > printf("%d %d\n",err,errno);
> > }
> >
> > I think that it should
On Mon, 2005-03-14 at 17:48 +0300, Evgeniy wrote:
> Here is a simple program.
>
> #include
> #include
> main(){
> int err;
> err=read(0,NULL,6);
> printf("%d %d\n",err,errno);
> }
>
> I think that it should be an error : Null pointer assignment, like in windows.
> But in practise it is no
On Friday, 13 April 2001, at 08:56:23 +0200,
Jan Gregor wrote:
> Hi
> Kernel 2.2.19 downloaded from www.kernel.org sometimes when I boot from lilo
> reports after "uncompressing linux ..." and blank line shows "crc error"
> and halts.
> [...]
>
Same behavior here, as I reported some days ago on
> I believe there is a bug in Linux Kernel 4.2. I tried Kernels 2.4.2 and 2.4.0
> with my german SuSE-Distribution (7.1).
> The problem occurs with my SCSI MO drive. while it works fine with Kernel
> 2.2.18 on the same machine and distribution, the behaviour with the newer
SCSI M/O drives with
51 matches
Mail list logo
