> "marco" == marco gaddoni <[EMAIL PROTECTED]> writes:
marco> i got this oops on my server. the kernel is a
marco> 2.6.21-2-686 from the debian.
marco> this is an ext3 filesystem on a raid0 array of 2 ide disks.
marco> got the oops while doing a big rm.
marco> any idea on the possible cause
]
kernel BUG at mm/slab.c:597!
invalid opcode: [#1]
SMP
Modules linked in: nfs nf_conntrack_ftp nfsd exportfs lockd nfs_acl
sunrpc ipt_MASQUERADE ipt_LOG ip6table_filter ip6_tables xt_state
xt_tcpmss xt_tcpudp ipt_addrtype xt_pkttype iptable_raw xt_CLASSIFY
xt_CONNMARK xt_MARK xt_comment
Andrew Morton wrote:
> On Tue, 20 Mar 2007 00:25:02 +0100
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
>> Mike Christie wrote:
>>> Mike Christie wrote:
James Bottomley wrote:
> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>> I can't even say if the tapes are written co
On Tue, 20 Mar 2007 00:25:02 +0100
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> Mike Christie wrote:
> > Mike Christie wrote:
> >> James Bottomley wrote:
> >>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
> > I can't even say if the tapes are written correctly as I can't read them
On Monday 19 March 2007, James Bottomley wrote:
>On Mon, 2007-03-19 at 17:47 -0400, Gene Heskett wrote:
>> James, could this also be the cause of a tar based backup going crazy
>> and thinking all data is new under any 2.6.21-rc* kernel I've tested
>> so far with amanda, which in my case uses tar?
Mike Christie wrote:
> James Bottomley wrote:
>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.
Mike Christie wrote:
> Mike Christie wrote:
>> James Bottomley wrote:
>>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
> I can't even say if the tapes are written correctly as I can't read them
> (one does not reboot production machines back to 2.4.x just to try to
> read a b
On Mon, 2007-03-19 at 17:47 -0400, Gene Heskett wrote:
> James, could this also be the cause of a tar based backup going crazy and
> thinking all data is new under any 2.6.21-rc* kernel I've tested so far
> with amanda, which in my case uses tar? I've tried the fedora patched
> tar-1.15-1, and
On Monday 19 March 2007, James Bottomley wrote:
>On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>> > I can't even say if the tapes are written correctly as I can't read
>> > them (one does not reboot production machines back to 2.4.x just to
>> > try to read a backup tape - I don't have 2.
Mike Christie wrote:
> James Bottomley wrote:
>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.
James Bottomley wrote:
> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>> I can't even say if the tapes are written correctly as I can't read them
>>> (one does not reboot production machines back to 2.4.x just to try to
>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on th
On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
> > I can't even say if the tapes are written correctly as I can't read them
> > (one does not reboot production machines back to 2.4.x just to try to
> > read a backup tape - I don't have 2.6.x older than 2.6.20 on these
> > machines).
>
> C
Andreas Steinmetz wrote:
> As posted to lkml and linux-scsi on 2007-03-15 without reply, see
> http://marc.info/?l=linux-kernel&m=117395128412313&w=2 for original post:
>
> It is not so nice when one can write backup tapes but the tapes cannot
> be read. I don't know if memory management or the st
On 3/19/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
You can see that mempool_free is passing a NULL pointer to
kmem_cache_free() which doesn't handle it properly. The NULL pointer
comes from bio_free() where ->bi_io_vec is NULL because nr_iovecs
passed to bio_alloc_bioset() was zero.
The questi
On 3/19/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14
ds: 007b es: 007b ss: 0068
But somehow eax and edx have the same value 0xc18
On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
BUG_ON(!PageSlab(page));
that's seriously screwed up. Do you have CONFIG_DEBUG_SLAB enabled? If
not, please enable it and retest.
This is scary. Looking at disassembly of the OOPS:
Disassembly of section .text:
<.text>:
On Mon, 19 Mar 2007 01:34:22 +0100 Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> As posted to lkml and linux-scsi on 2007-03-15 without reply, see
> http://marc.info/?l=linux-kernel&m=117395128412313&w=2 for original post:
Repeatable oops in our most recently released kernel, nobody bothers to
r
As posted to lkml and linux-scsi on 2007-03-15 without reply, see
http://marc.info/?l=linux-kernel&m=117395128412313&w=2 for original post:
It is not so nice when one can write backup tapes but the tapes cannot
be read. I don't know if memory management or the st driver is the
culprit, but this is
Got the following on executing "tar tpf /dev/st0l" on two different
systems (x86):
kernel BUG at mm/slab.c:597!
invalid opcode: [#1]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.20.3-luna #1)
19 matches
Mail list logo
