Alexey Dobriyan wrote:
On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote:
Rank 3: remove_proc_entry
WARN_ON at fs/proc/generic.c:736
Reported 20 times (38 total reports)
This WARN_ON is there if code tries to remove a non-empty /proc
directory.
Most
On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote:
> Rank 3: remove_proc_entry
> WARN_ON at fs/proc/generic.c:736
> Reported 20 times (38 total reports)
> This WARN_ON is there if code tries to remove a non-empty /proc
> directory.
> Most reports are
On Monday 11 February 2008 11:35, Arjan van de Ven wrote:
> The http://www.kerneloops.org website collects kernel oops and
> warning reports from various mailing lists and bugzillas as well as
> with a client users can install to auto-submit oopses.
> Below is a top 10 list of the
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses/backtraces collected in the last 7 days.
(Reports prior to 2.6.23 have
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses/backtraces collected in the last 7 days.
(Reports prior to 2.6.23 have
On Monday 11 February 2008 11:35, Arjan van de Ven wrote:
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses/backtraces
Alexey Dobriyan wrote:
On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote:
Rank 3: remove_proc_entry
WARN_ON at fs/proc/generic.c:736
Reported 20 times (38 total reports)
This WARN_ON is there if code tries to remove a non-empty /proc
directory.
Most
On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote:
Rank 3: remove_proc_entry
WARN_ON at fs/proc/generic.c:736
Reported 20 times (38 total reports)
This WARN_ON is there if code tries to remove a non-empty /proc
directory.
Most reports are
[summary for folks who want to skip blow-by-blow: it's missing check for
hfs_bnode_find() returning ERR_PTR(), there are 2 more places like that
in fs/hfs/* (all in brec.c) and graceful recovery may be non-obvious]
Text below is mostly for the benefit of newbies - it's more along the
lines of
[summary for folks who want to skip blow-by-blow: it's missing check for
hfs_bnode_find() returning ERR_PTR(), there are 2 more places like that
in fs/hfs/* (all in brec.c) and graceful recovery may be non-obvious]
Text below is mostly for the benefit of newbies - it's more along the
lines of
(this one looks like it should go to netdev as well - added to Cc)
On 10/08/07, Sinisa Segvic <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've just got a kernel oops.
>
> http://lxr.linux.no/source/Documentation/oops-tracing.txt
> seems to suggest that oops reports are welcome at this address.
>
>
Hi,
I've just got a kernel oops.
http://lxr.linux.no/source/Documentation/oops-tracing.txt
seems to suggest that oops reports are welcome at this address.
Cheers,
Sinisa
$ uname -a
Linux PCs129.EMT.tugraz.at 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC
2007 i686 GNU/Linux
[326735.692443]
(this one looks like it should go to netdev as well - added to Cc)
On 10/08/07, Sinisa Segvic [EMAIL PROTECTED] wrote:
Hi,
I've just got a kernel oops.
http://lxr.linux.no/source/Documentation/oops-tracing.txt
seems to suggest that oops reports are welcome at this address.
Cheers,
Hi,
I've just got a kernel oops.
http://lxr.linux.no/source/Documentation/oops-tracing.txt
seems to suggest that oops reports are welcome at this address.
Cheers,
Sinisa
$ uname -a
Linux PCs129.EMT.tugraz.at 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC
2007 i686 GNU/Linux
[326735.692443]
hi all
i found an oops on my screen this morning. in all likelihood, it's
just a delayed crash due to some network experimentation i was doing
yesterday, but it seemed severe enough to post to the list, just in
case it's real.
kernel BUG at fs/buffer.c:2890!
invalid operand: [#1]
hi all
i found an oops on my screen this morning. in all likelihood, it's
just a delayed crash due to some network experimentation i was doing
yesterday, but it seemed severe enough to post to the list, just in
case it's real.
kernel BUG at fs/buffer.c:2890!
invalid operand: [#1]
[1.] One line summary of the problem:
OOPS report for L2 cacheable size setting at 512MB on TD5TH dual P200
[2.] Full description of the problem/report:
My system board BIOS has two settings for L2 cacheable size: 64MB and
512MB. Previous kernels would lock when initialising the
framebuffer
[1.] One line summary of the problem:
OOPS report for L2 cacheable size setting at 512MB on TD5TH dual P200
[2.] Full description of the problem/report:
My system board BIOS has two settings for L2 cacheable size: 64MB and
512MB. Previous kernels would lock when initialising the
framebuffer
On Friday, March 16, 2001 01:03:20 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
>> Ok, I was more talking about the ugliness that is reiserfs_panic (how
>> many times do we need a commented out for(;;)?). For panic() calling
>> sys_sync, I think there non-filesystem related panics where
On Fri, 16 Mar 2001, Chris Mason wrote:
> > I suspect that the right fix is to drop the ->s_lock bogosity along with
> > sys_sync() call in panic()...
>
> Ok, I was more talking about the ugliness that is reiserfs_panic (how many
> times do we need a commented out for(;;)?). For panic()
On Friday, March 16, 2001 12:32:56 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 16 Mar 2001, Chris Mason wrote:
>
>> > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
>> > _never_ tries to do any block IO. It looks like a rudiment of something
>> >
On Thursday, March 15, 2001 09:44:48 PM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 15 Mar 2001, David wrote:
>
>> 2.4.2-ac4
>>
>> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
>> 16:41 (hdd), sector 9512
>> Mar 15 18:02:49 Huntington-Beach kernel:
On Fri, 16 Mar 2001, Chris Mason wrote:
> > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
> > _never_ tries to do any block IO. It looks like a rudiment of something
> > that hadn't been there for 5 years, if not longer. The same goes for
> > ext2_panic() and ufs_panic(),
On Thu, 15 Mar 2001, David wrote:
> 2.4.2-ac4
>
> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
> 16:41 (hdd), sector 9512
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for
2.4.2-ac4
Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
16:41 (hdd), sector 9512
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:49 Huntington-Beach kernel:
2.4.2-ac4
Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
16:41 (hdd), sector 9512
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:49 Huntington-Beach kernel:
On Thursday, March 15, 2001 09:44:48 PM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
On Thu, 15 Mar 2001, David wrote:
2.4.2-ac4
Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
16:41 (hdd), sector 9512
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not
On Fri, 16 Mar 2001, Chris Mason wrote:
I suspect that the right fix is to drop the -s_lock bogosity along with
sys_sync() call in panic()...
Ok, I was more talking about the ugliness that is reiserfs_panic (how many
times do we need a commented out for(;;)?). For panic() calling
On Friday, March 16, 2001 01:03:20 AM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
Ok, I was more talking about the ugliness that is reiserfs_panic (how
many times do we need a commented out for(;;)?). For panic() calling
sys_sync, I think there non-filesystem related panics where we do
--- Henrik Stokseth <[EMAIL PROTECTED]> wrote:
> you were the one with the gcc 2.95.3 compiler right? even though this
> compiler is a prerelease of a stable branch i have confirmed errors
> in the
> optimalization passes. my advice: use a compiler which really IS
> stable
> (gcc-2.95.2 or
--- Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Details please.
>
>
> Bernd
Processor:
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 451.034
cache size : 64 KB
On Mon, 22 Jan 2001, Henrik Stokseth wrote:
> you were the one with the gcc 2.95.3 compiler right? even though this
> compiler is a prerelease of a stable branch i have confirmed errors in the
> optimalization passes.
Details please.
Bernd
-
To unsubscribe from this list: send the line
On Mon, 22 Jan 2001, Henrik Stokseth wrote:
you were the one with the gcc 2.95.3 compiler right? even though this
compiler is a prerelease of a stable branch i have confirmed errors in the
optimalization passes.
Details please.
Bernd
-
To unsubscribe from this list: send the line
--- Bernd Schmidt [EMAIL PROTECTED] wrote:
Details please.
Bernd
Processor:
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 451.034
cache size : 64 KB
fdiv_bug
--- Henrik Stokseth [EMAIL PROTECTED] wrote:
you were the one with the gcc 2.95.3 compiler right? even though this
compiler is a prerelease of a stable branch i have confirmed errors
in the
optimalization passes. my advice: use a compiler which really IS
stable
(gcc-2.95.2 or egcs-1.1.2 are
Henrik Stokseth writes:
> you were the one with the gcc 2.95.3 compiler right? even though this
> compiler is a prerelease of a stable branch i have confirmed errors in the
> optimalization passes. my advice: use a compiler which really IS stable
> (gcc-2.95.2 or egcs-1.1.2 are fine), or turn off
- Original Message -
From: Tom <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 22, 2001 2:11 PM
Subject: Proper OOPS report
> My apologies for not running it through ksymoops.
> No specific bit of code was referenced in the OOPS so I am assuming
>
My apologies for not running it through ksymoops.
No specific bit of code was referenced in the OOPS so I am assuming
it is in the kernel itself.
Tom
Jan 21 22:02:36 hrafn kernel: c0108f75
Jan 21 22:02:36 hrafn kernel: Oops:
Jan 21 22:02:36 hrafn kernel: CPU:0
Jan 21 22:02:36 hrafn
My apologies for not running it through ksymoops.
No specific bit of code was referenced in the OOPS so I am assuming
it is in the kernel itself.
Tom
Jan 21 22:02:36 hrafn kernel: c0108f75
Jan 21 22:02:36 hrafn kernel: Oops:
Jan 21 22:02:36 hrafn kernel: CPU:0
Jan 21 22:02:36 hrafn
- Original Message -
From: Tom [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 22, 2001 2:11 PM
Subject: Proper OOPS report
My apologies for not running it through ksymoops.
No specific bit of code was referenced in the OOPS so I am assuming
it is in the kernel itself
Henrik Stokseth writes:
you were the one with the gcc 2.95.3 compiler right? even though this
compiler is a prerelease of a stable branch i have confirmed errors in the
optimalization passes. my advice: use a compiler which really IS stable
(gcc-2.95.2 or egcs-1.1.2 are fine), or turn off all
be reliable.
The kernel configuration file is included as an attachment. I also
included the output of dmesg for when the kernel boots after a warm
start
and the contents of /proc/pci in the same case.
Please CC me on responses to this oops report as I am not subscribed
to the kernel-li
is included as an attachment. I also
included the output of dmesg for when the kernel boots after a warm
start
and the contents of /proc/pci in the same case.
Please CC me on responses to this oops report as I am not subscribed
to the kernel-list.
Thanks,
Markus
#
# Automatically generated
[root@cr957697-a ksymoops]# ./ksymoops < the_oops.txt
WARNING: This version of ksymoops is obsolete.
WARNING: The current version can be obtained from ftp://ftp.ocs.com.au/pub/ksymoops
Options used: -V (default)
-o /lib/modules/2.2.16-22/ (default)
-k /proc/ksyms
[root@cr957697-a ksymoops]# ./ksymoops the_oops.txt
WARNING: This version of ksymoops is obsolete.
WARNING: The current version can be obtained from ftp://ftp.ocs.com.au/pub/ksymoops
Options used: -V (default)
-o /lib/modules/2.2.16-22/ (default)
-k /proc/ksyms
On Fri, Nov 10 2000, Henning P. Schmiedehausen wrote:
[snip]
> Running 2.2.18pre17 completely modular built + 20001027 IDE patch from
> kernel.org + Andreas' 2.2.18pre17aa1 patch + some more but I think not
> related patches. Complete Kernel SRPMS and RPMS on request. :-)
> The Mitsumi CDROM is
[ Ok, so my first mail seems to never have it made to the list. :-( ]
Hi,
the following situation:
Intel Celeron 667, 128 MB RAM, 440BX-based board (ASUS CUBX)
IBM 30 GB Disk and TEAC CDROM on ide0
LS120 Floppy and a Mitsumi CDROM on ide1 (see boot messages below for details)
Once upon a
[ Ok, so my first mail seems to never have it made to the list. :-( ]
Hi,
the following situation:
Intel Celeron 667, 128 MB RAM, 440BX-based board (ASUS CUBX)
IBM 30 GB Disk and TEAC CDROM on ide0
LS120 Floppy and a Mitsumi CDROM on ide1 (see boot messages below for details)
Once upon a
On Fri, Nov 10 2000, Henning P. Schmiedehausen wrote:
[snip]
Running 2.2.18pre17 completely modular built + 20001027 IDE patch from
kernel.org + Andreas' 2.2.18pre17aa1 patch + some more but I think not
related patches. Complete Kernel SRPMS and RPMS on request. :-)
The Mitsumi CDROM is used
Matthew Dharm wrote:
>
> Yet more followup with myself I can reproduce this problem on
> 2.4.0-test10-pre1 every time. I'm using the ide-scsi and usb-storage
> modules to trigger the bug -- loading and then unloading either one causes
> /proc/scsi to not be cleaned up properly.
>
> As yet,
bove for symbol resolution.
> If the current kernel and/or modules do not match the log, you can get
> more accurate output by telling me the kernel version and where to find
> map, modules, ksyms etc. ksymoops -h explains the options.
>
> Reading Oops report from the terminal
> Unable t
the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Reading Oops report from the terminal
Unable to handle kernel paging request at virtual address d38c2010
c0145032
*pde = 01594063
Oops: 0002
Matthew Dharm wrote:
Yet more followup with myself I can reproduce this problem on
2.4.0-test10-pre1 every time. I'm using the ide-scsi and usb-storage
modules to trigger the bug -- loading and then unloading either one causes
/proc/scsi to not be cleaned up properly.
As yet, nobody
explains the options.
Reading Oops report from the terminal
Unable to handle kernel paging request at virtual address d38c2010
c0145032
*pde = 01594063
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d38c2000 ebx: cf93f0a0 ecx
Hi,
Trying to play a file with mpg123 from ntfs partition got this:
(test9-pre8 and repeatable at least with mpg123, also test9-pre7 gave
similar one. I havent tried this with earlier versions)
Oct 2 17:45:28 eepc08 kernel: kernel BUG at fs.c:568!
Oct 2 17:45:28 eepc08 kernel: invalid
explains the options.
Reading Oops report from the terminal
Unable to handle kernel paging request at virtual address d38c2010
c0145032
*pde = 01594063
Oops: 0002
CPU:0
EIP:0010:[c0145032]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d38c2000 ebx: cf93f0a0 ecx
Just to follow-up to my own post, I have some more datapoints...
The bug definatley seems to be in either the SCSI layer or the procfs
layer. The behavior is the same if I use either ide-scsi or usb-storage,
which are the only two SCSI modules I can test.
Matt
On Fri, Sep 29, 2000 at
I'm using 2.4.0-test9-pre7 and have a _very_ reproducable OOPS with the
SCSI layer. Everything relevant is compiled as a module (except for the
/proc support).
The test scenario is this:
(1) Boot the machine
(2) modprobe ide-scsi (note this autoloads scsi_mod but nothing else)
(3) rmmod
I'm using 2.4.0-test9-pre7 and have a _very_ reproducable OOPS with the
SCSI layer. Everything relevant is compiled as a module (except for the
/proc support).
The test scenario is this:
(1) Boot the machine
(2) modprobe ide-scsi (note this autoloads scsi_mod but nothing else)
(3) rmmod
59 matches
Mail list logo
