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
Hi, Thomas
I canceled that patch. In my testing, that will not fix the problem.
Why the IRQ is unexpectedly masked, that is not an easy bug for me.
More time need to hacking the driver/kernel code.
Thanks for your reply.
Thomas Gleixner 于2019年10月14日周一 下午8:34写道：
>
> On Tue, 8 Oct 2019, Yi Zheng
On Tue, 8 Oct 2019, Yi Zheng wrote:
> There is some defects on IRQ processing:
>
> (1) At the beginning of handle_level_irq(), the IRQ-28 is masked, and ACK
> action is executed: On my machine, it runs the 'else' branch:
>
> static inline void mask_ack_irq(struct ir
* Yi Zheng [191010 06:22]:
> Hi
>
>My patch is canceled. I have tested that simple adjustment, the
> device IRQ masked unexpectedly. It seems that it is more easily to
> occur with that patch.
>
> So, the root cause is not found yet.
OK. Based on your description, it could be a missing flus
Hi
My patch is canceled. I have tested that simple adjustment, the
device IRQ masked unexpectedly. It seems that it is more easily to
occur with that patch.
So, the root cause is not found yet.
Hi,
* Yi Zheng [191008 13:06]:
> NOTE: (1) My SoC is a single core ARM chip: TI-AM3352, so the raw
> spin-lock irq_desc->lock will be optimized to
> nothing. handle_level_irq() has no spin-lock protection, right?
Well not always, With CONFIG_SMP we modify only some of the
Hi,
I found something wrong on my AM3352 SoC machine, the GPIO triggered IRQ is
masked unexpectedly. That bug cause the devices using that GPIO-IRQ can
not work. Even the latest kernel version (v5.4-rc2-20-geda57a0e4299)!
After a long time hacking, I guess the bug is in kerne
Hi,
I found something wrong on my AM3352 SoC machine, the GPIO
triggered IRQ is masked
unexpectedly. That bug cause the devices using that GPIO-IRQ can
not work. Even the
latest kernel version (v5.4-rc2-20-geda57a0e4299)!
After a long time hacking, I guess the bug is in
kerne
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "kernel/cgroup"
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "kernel/cgroup"
The kernel module is loaded into vmalloc region which is located below
to the PAGE_OFFSET. Hence the condition, pc < PAGE_OFFSET, in the
is_valid_bugaddr() will filter out all trap exceptions triggered
by kernel module. To support BUG() in kernel module, the condition is
changed to
The kernel module is loaded into vmalloc region which is located below
to the PAGE_OFFSET. Hence the condition, pc < PAGE_OFFSET, in the
is_valid_bugaddr() will filter out all trap exceptions triggered
by kernel module. To support BUG() in kernel module, the condition is
changed to
On Sat, Jan 07, 2017 at 05:11:38PM +0100, Wim Osterholt wrote:
> On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
>
> L.S.,
> >
> > after appearance of kernel-4.10-rc1 two days ago...
>
> A quickly following release of 4.10-rc2 made sure that lirc_dev was loaded
> together with ser
On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
L.S.,
>
> after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
> to find a question about lirc_serial in 'make oldconfig':
>
> Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
> Serial Port T
L.S.,
after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
to find a question about lirc_serial in 'make oldconfig':
Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y
I was used to 'lirc_serial: mo
On Fri, Aug 10, 2012 at 4:53 AM, Victor Meyerson
wrote:
> I tried that patch, although I had to edit a slightly different line as
> dio_bio_alloc was near line 392 instead of 349 in the version of
> fs/direct-io.c in my tree. I still got different checksums between the two
> files and even dif
- Original Message -
> From: Hillf Danton
> To: Victor Meyerson
> Cc: "linux-m...@linux-mips.org" ; Ralf Baechle
> ; LKML
> Sent: Friday, July 27, 2012 7:47 AM
> Subject: Re: Direct I/O bug in kernel
>
> On Wed, Jul 25, 2012 at 1:28 AM, Victo
On Wed, Jul 25, 2012 at 1:28 AM, Victor Meyerson
wrote:
>
> Still different checksums and I used the same random-file from my first test.
>
Then try the fix at
https://lkml.org/lkml/2012/7/27/54
Good Weekend
Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
- Original Message -
> From: Hillf Danton
> To: Victor Meyerson
> Cc: "linux-m...@linux-mips.org" ; Ralf Baechle
> ; LKML
> Sent: Tuesday, July 24, 2012 6:04 AM
> Subject: Re: Direct I/O bug in kernel
>
> On Sun, Jul 22, 2012 at 10:05 AM, Victor Me
On Sun, Jul 22, 2012 at 10:05 AM, Victor Meyerson
wrote:
> Hi,
>
> I recently found a bug related to direct io in post 3.3 linux kernels.
> Fortunately, my hardware (a Cobalt Qube2) is supported by the vanilla kernel
> so I did not need additional patch sets to get the machine to boot. I ran
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 19 Jul 2007 21:09:09 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > Coverity spotted what looks like a real possible case of using a
> > variable after it has been freed.
> > The problem is in kernel/relay.c::relay_open_buf()
> >
>
On Thu, 19 Jul 2007 21:09:09 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Coverity spotted what looks like a real possible case of using a
> variable after it has been freed.
> The problem is in kernel/relay.c::relay_open_buf()
>
> If the code hits "goto free_buf;" it ends up in this cod
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits "goto free_buf;" it ends up in this code :
free_buf:
relay_destroy_buf(buf); <--- calls kfree() on 'buf'.
free_name:
On 19/07/07, David J. Wilder <[EMAIL PROTECTED]> wrote:
ACK
Thanks for catching this. Your patch looks fine. I tested for
regression, no problems. I also tested the error path and had the
expected results.
Ok, thank you for testing. I see that Mathieu Desnoyers also ack'ed
the patch (thank you
* Jesper Juhl ([EMAIL PROTECTED]) wrote:
> Hi,
>
> Coverity spotted what looks like a real possible case of using a
> variable after it has been freed.
> The problem is in kernel/relay.c::relay_open_buf()
>
> If the code hits "goto free_buf;" it ends up in this code :
>
> free_buf:
> re
ACK
Thanks for catching this. Your patch looks fine. I tested for
regression, no problems. I also tested the error path and had the
expected results.
Thanks
Dave
Jesper Juhl wrote:
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The pr
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits "goto free_buf;" it ends up in this code :
free_buf:
relay_destroy_buf(buf); <--- calls kfree() on 'buf'.
free_n
Hi,
I am using kernel-rt on my FC6/x86-64 system,
the CPU is an Athlon64 X2.
It locks up very rarely (I haven't found any sign in the logs for that)
but I always get this on shutdown, I wonder if it might be related
to the lockup:
Mar 5 23:53:52 static-81-17-177-202 kernel: BUG: using
smp_pro
Andrew,
On Thu, Mar 01, 2007 at 04:47:42PM -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 15:32:22 +0100
> "Uwe Bugla" <[EMAIL PROTECTED]> wrote:
>
> > Hi folks,
> > this patch fixes the floppy mount bug (i. e. regression) in kernel
> > 2.6.21-rc1. It was inspired by Stephane Eranian. It was
On Thu, 01 Mar 2007 15:32:22 +0100
"Uwe Bugla" <[EMAIL PROTECTED]> wrote:
> Hi folks,
> this patch fixes the floppy mount bug (i. e. regression) in kernel
> 2.6.21-rc1. It was inspired by Stephane Eranian. It was tested on an Intel P4
> 1800 MHz
> (Intel ICH4 chipset) and on an AMD Athlon XP 180
Hi folks,
this patch fixes the floppy mount bug (i. e. regression) in kernel 2.6.21-rc1.
It was inspired by Stephane Eranian. It was tested on an Intel P4 1800 MHz
(Intel ICH4 chipset) and on an AMD Athlon XP 1800 MHz (Silicon Integrated
Systems chipset 740, 5513).
My deep thanks and respect go t
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
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.6.20-git10 and
2.6.20-git14.
"I'm afraid that the most proac
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
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 ambiguous: "We did not break it"
Once again and for the last time: I do not state that f
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
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.
Mandrake Linux kernel 2.4.21-0.13mdk
I am a programmer too and i am
On Thu, Jan 20, 2005 at 10:10:49PM +0100, Alexander Fieroch wrote:
> Hello kernel list,
>
> I don't know if this is the right list for problems with kernel modules
> and bugs - if not please tell me where I can find the kernel development
> mailing list to report this.
This is the right list, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello kernel list,
I don't know if this is the right list for problems with kernel modules
and bugs - if not please tell me where I can find the kernel development
mailing list to report this.
So here is my problem:
I get errors when I try to copy files
On Tue, 22 May 2001 22:52:47 +1000, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Carlos Laviola wrote:
> >
> > invalid operand:
[ ... oops here ... ]
> > Segmentation fault
> >
> > This seems to be a bug in the kernel, maybe because the file is too big,
> > and VFAT partitions don't like tha
Carlos Laviola wrote:
>
> invalid operand:
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010282
> eax: 0019 ebx: ecx: c1272000 edx: c3f7bc20
> esi: 00206c60 edi: c3ca5240 ebp: c0695aa0 esp: c1273e68
> ds: 0018 es: 0018 ss: 0018
> Process snarf (pid: 324, stackpage=c1
I was getting the file ias9i_linux.tar from
http://xxx:[EMAIL PROTECTED]/otn/linux/ias/9ias/ias9i_linux.tar
(username and password masked to protect the innocent) and decided to take
a peek at the contents of that (huge) file, using "tar xfv ias9i_linux.tar".
After a few moments, wget segfaulted.
In working on thread core dumps I've stumbled across a minor bug in the
generic `fork' code. The problem code is in routine `copy_mm' in
`kernel/fork.c':
/* Copy the current MM stuff.. */
memcpy(mm, oldmm, sizeof(*mm));
.
.
.
if (retval)
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
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. I looked at the sources and found that this means that uncompressed
kernel has bad crc. I tried compile it under debian potato (gcc 2
> 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
Hello,
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
Kernels is like that:
Well, someone using ne2000 chipset have same problem-drop connection
some people already post in mail list, but the sound like no one
interested about our problem
it will auto drop connection when used a long time ( over 24 hours )
I can not use ifconfig to restart the interface, so I must r
On Sun, Feb 11, 2001 at 05:33:35AM -0200, Marcel Silva e Sousa wrote:
> Hi all, i see a critical bug in kernel version 2.4.0 and 2.4.1, look it:
>
> My Hard Disk:
> hda: IBM-DPTA-372730, ATA DISK drive
> hda: 53464320 sectors (27374 MB) w/1961KiB Cache, CHS=3328/255/63, UDMA(33)
Hi all, i see a critical bug in kernel version 2.4.0 and 2.4.1, look it:
i use Linux Slackware 7.1
My Hard Disk:
hda: IBM-DPTA-372730, ATA DISK drive
hda: 53464320 sectors (27374 MB) w/1961KiB Cache, CHS=3328/255/63, UDMA(33)
I have instaled in this hard disk 3 OS (OpenBSD, Linux Slack and
I stumbled upon a strange bug in the 2.4.0-test[9-10] kernels,
which only happens on PII (Deschutes) processors: right after boot, it
starts spitting "floating point exception"s all over the place, every time
aborting the program it was executing. This begins to happen very early,
before a
96 matches
Mail list logo
