I am using dm-crypt to encrypt SD card in Android Gingerbread and got kernel panic after encrypting 700 MB (SD card is 2 GB).
Blow is kernel log when kernel panic happened. I need help to figout what triggered kernel panic.
Thanks
Fan
<6>[ 2184.049510] sec-battery sec-battery: sec_bat_set_property: topoff intr
<6>[ 2184.049582] max8997-charger max8997-charger: max8997_disable_charging: disable charging
<6>[ 2184.050214] max8997-charger max8997-charger: Topoff IRQ occurred!
<1>[ 2184.050540] Unable to handle kernel NULL pointer dereference at virtual address 00000000
<6>[ 2184.050709] max8997 5-0066: max8997_irq_thread: irq:331, irq_src:0x0
<4>[ 2184.050769] max8997 5-0066: Unused interrupt source: 0x0
<1>[ 2184.050863] pgd = c0004000
<1>[ 2184.050901] [00000000] *pgd=00000000
<0>[ 2184.050966] Internal error: Oops: 17 [#1] PREEMPT SMP
<0>[ 2184.051015] last sysfs file: /sys/devices/platform/s3c2410-i2c.5/i2c-5/5-0066/max8997-muic/usb_sel
<4>[ 2184.051081] Modules linked in: j4fs(P) Si4709_driver bthid vibrator
<4>[ 2184.051206] CPU: 0 Tainted: P B W (2.6.35.7 #273)
<4>[ 2184.051303] PC is at page_address+0x14/0xf0
<4>[ 2184.051366] LR is at blk_rq_bio_prep+0x74/0xb0
<4>[ 2184.051428] pc : [<c040e268>] lr : [<c04feb60>] psr: 20000013
<4>[ 2184.051460] sp : efef7d98 ip : efef7dc0 fp : efef7dbc
<4>[ 2184.051514] r10: c0b14680 r9 : 0b300010 r8 : 00000000
<4>[ 2184.051567] r7 : c0b14f40 r6 : 0000000c r5 : f0e0f750 r4 : e7571480
<4>[ 2184.051624] r3 : 00000000 r2 : e75714c8 r1 : e7571480 r0 : 00000000
<4>[ 2184.051688] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
<4>[ 2184.051753] Control: 10c53c7d Table: 70d8004a DAC: 00000017
<4>[ 2184.051803]
<4>[ 2184.051816] PC: 0xc040e1e8:
<4>[ 2184.051848] e1e8 e5843008 e5836004 e5826000 e584200c e1a01000 e59f0044 eb1031bd e89dadf0
<4>[ 2184.052014] e208 e2434008 e1a06004 e5b63008 f5d3f000 e1560005 1affffe1 e1a00008 eafffff5
<4>[ 2184.052178] e228 e59f0014 e3001173 ebfd089f c0b136c0 9e370001 c0b68e20 c0b66e00 c092f8af
<4>[ 2184.052340] e248 c0b69e20 00100100 00200200 e1a0c00d e92ddbf0 e24cb004 e92d4000 e8bd4000
<4>[ 2184.052503] e268 e5902000 e59f10c0 e1a04000 e7e13d52 e3a00e32 e0231390 e593130c e0613003
<4>[ 2184.052667] e288 e1530000 1a00001c e59f80a0 e59f70a0 e0080498 e1a08ca8 e0875288 e2856008
<4>[ 2184.052829] e2a8 e1a00006 eb10323b e7973288 e1530005 12433008 e1a01000 1a000005 ea000009
<4>[ 2184.052992] e2c8 e5932000 e1520004 05934004 0a000006 e2403008 e1a02003 e5b20008 f5d0f000
<4>[ 2184.053159]
<4>[ 2184.053173] LR: 0xc04feae0:
<4>[ 2184.053206] eae0 e3540000 1affffee e89dadf0 e1a0c00d e92dd8f0 e24cb004 e92d4000 e8bd4000
<4>[ 2184.053370] eb00 e5923014 e1a04002 e3520000 e5912020 e2033001 e1a05001 e1823003 e5813020
<4>[ 2184.053533] eb20 0a000014 e5943038 e3530000 0a000011 e1a01004 ebfd59dd e1c507b0 e1d431b8
<4>[ 2184.053696] eb40 e3530000 0a00000a e1d431ba e3a0600c e5942038 e0030396 e7920003 ebfc3dbc
<4>[ 2184.053860] eb60 e5943038 e1d421ba e0263296 e5963008 e0803003 e585307c e5943020 e5854044
<4>[ 2184.054022] eb80 e5854040 e5853030 e594300c e3530000 1593306c 15853068 e89da8f0 e1a0c00d
<4>[ 2184.054185] eba0 e92dd830 e24cb004 e92d4000 e8bd4000 e1a0c001 e5911030 e3a02001 e5802024
<4>[ 2184.054347] ebc0 e1a03000 e5902020 e580102c e59c1014 e3110010 0201100e 1382200e 01822001
<4>[ 2184.054514]
<4>[ 2184.054528] SP: 0xefef7d18:
<4>[ 2184.054560] 7d18 ffffffff efef7d84 0000000c c0b14f40 00000000 20000113 ffffffff efef7d84
<4>[ 2184.054723] 7d38 0000000c c0b14f40 efef7dbc efef7d50 c034bcec c034b4e0 00000000 e7571480
<4>[ 2184.054885] 7d58 e75714c8 00000000 e7571480 f0e0f750 0000000c c0b14f40 00000000 0b300010
<4>[ 2184.055047] 7d78 c0b14680 efef7dbc efef7dc0 efef7d98 c04feb60 c040e268 20000013 ffffffff
<4>[ 2184.055210] 7d98 e7571480 f0e0f750 0000000c c0b14f40 00000000 0b300010 efef7ddc efef7dc0
<4>[ 2184.055372] 7db8 c04feb60 c040e260 e7571d80 00000000 f1741760 c0b14f40 efef7df4 efef7de0
<4>[ 2184.055534] 7dd8 c04fec70 c04feaf8 f1741760 00000001 efef7e34 efef7df8 c0501e0c c04feba8
<4>[ 2184.055696]
From: "dm-crypt-request@xxxxxxxx" <dm-crypt-request@xxxxxxxx>
To: dm-crypt@xxxxxxxx
Sent: Thursday, January 26, 2012 5:00 AM
Subject: dm-crypt Digest, Vol 31, Issue 24
To: dm-crypt@xxxxxxxx
Sent: Thursday, January 26, 2012 5:00 AM
Subject: dm-crypt Digest, Vol 31, Issue 24
Send dm-crypt mailing list submissions to
dm-crypt@xxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://www.saout.de/mailman/listinfo/dm-crypt
or, via email, send a message with subject or body 'help' to
dm-crypt-request@xxxxxxxx
You can reach the person managing the list at
dm-crypt-owner@xxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dm-crypt digest..."
Today's Topics:
1. Re: Kernel BUG (fs/bio.c:1499) when copying more files to an
encrypted device (Mandeep Singh Baines)
2. Re: Kernel BUG (fs/bio.c:1499) when copying more files to an
encrypted device (Mandeep Singh Baines)
----------------------------------------------------------------------
Message: 1
Date: Wed, 25 Jan 2012 10:20:27 -0800
From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
To: Luzipher McLeod <luziphermcleod@xxxxxxxx>
Cc: dm-crypt@xxxxxxxx, Mandeep Singh Baines <msb@xxxxxxxxxxxx>
Subject: Re: Kernel BUG (fs/bio.c:1499) when copying more
files to an encrypted device
Message-ID: <20120125182027.GJ4656@xxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
Luzipher McLeod (luziphermcleod@xxxxxxxx) wrote:
> Hi Mandeep,
>
> Thanks fpr your quick answer. So, what can be done about this ? Should I try to apply that patch you linked to ? (but I guess a patch from 2007 won't apply cleanly ...)
>
Hi Luzipher,
I wouldn't apply the patch directly. Just copy bio_multi_split (might
need to do some forward porting) and then modify linear_make_request to
use bio_multi_split instead of bio_split.
But I'm not really an expert on this particular code. I'm hoping someone
else will confirm that this is in fact the bug and not a side effect of
something else. Its seem reasonble that you could get a bio that is
multi-page and falls on a boundary (spans two or more devices). So I
suspect this is the bug.
Regards,
Mandeep
> Regards,
> Luzipher
>
>
>
> --- On Wed, 25/1/12, Mandeep Singh Baines <msb@xxxxxxxxxxxx> wrote:
>
> > From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
> > Subject: Re: [dm-crypt] Kernel BUG (fs/bio.c:1499) when copying more files to an encrypted device
> > To: "Luzipher McLeod" <luziphermcleod@xxxxxxxx>
> > Cc: dm-crypt@xxxxxxxx, "NeilBrown" <neilb@xxxxxxx>
> > Date: Wednesday, 25 January, 2012, 2:14
> > Luzipher McLeod (luziphermcleod@xxxxxxxx)
> > wrote:
> > > Hi :-)
> > >
> > > A few days ago I encountered a kernel bug while copying
> > files to an encrypted filesystem. The specific stack for the
> > filesystem is: btrfs-on-crypt-on-mdraid. Vasts amounts of
> > data copied without problems (about 6.3TB with 1.1 TB
> > remaining), but when copying a certain directory, the kernel
> > bug surfaces. I repeatedly deleted the affected directory
> > and tried to re-copy it, but it always fails at the same
> > point (or close to that). More recent test showed that I
> > could copy a few more files to the filesystem to a different
> > directory, but it very quickly failed there as well (a few
> > megabytes later).
> > > After talking to the btrfs devs on freenode (as btrfs
> > is the most experimental thing in the stack, they came to
> > the conclusion that it's most probably the crypto layer.
> > >
> > > Some details:
> > > gentoo kernel 3.2.1 (custom config and ubuntu config)
> > > mdraid: linear, 4 disks, each 2TB (total 8TB)
> > > crypt: setup via cryptsetup -c aes-xts-plain64 -h plain
> > -s 512 -d - create tempraid /dev/md/tempraid_lin
> > >
> > > I'd appreciate any help with this and would be happy to
> > test patches or provide more debug info.
> > >
> > > Thanks and Regards,
> > > Luzipher
> > >
> > >
> > >
> > >
> > > The kernel bug output retrieved by netconsole (also at
> > http://pastebin.com/sjJy7QE4 ):
> > >? ???[? 294.538422] netconsole:
> > local port 6666
> > >? ???[? 333.423583] SysRq :
> > Changing Loglevel
> > >? ???[? 333.423609] Loglevel
> > set to 9
> > >? ???[? 424.248405]
> > ------------[ cut here ]------------
> > >? ???[? 424.248447] kernel BUG
> > at fs/bio.c:1499!
> >
> > Hi Luzipher,
> >
> > Looks like the BUG is because bio_split only works on
> > single-page iovecs.
> >
> > I see a relevant (old) patch from Neil Brown here:
> >
> > https://lkml.org/lkml/2007/7/30/496
> >
> > Regards,
> > Mandeep
> >
>
------------------------------
Message: 2
Date: Wed, 25 Jan 2012 15:46:12 -0800
From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
To: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
Cc: dm-crypt@xxxxxxxx, linux-raid@xxxxxxxxxxxxxxx, Luzipher McLeod
<luziphermcleod@xxxxxxxx>
Subject: Re: Kernel BUG (fs/bio.c:1499) when copying more
files to an encrypted device
Message-ID: <20120125234612.GM4656@xxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
+cc linux-raid
Mandeep Singh Baines (msb@xxxxxxxxxxxx) wrote:
> Luzipher McLeod (luziphermcleod@xxxxxxxx) wrote:
> > Hi Mandeep,
> >
> > Thanks fpr your quick answer. So, what can be done about this ? Should I try to apply that patch you linked to ? (but I guess a patch from 2007 won't apply cleanly ...)
> >
>
> Hi Luzipher,
>
> I wouldn't apply the patch directly. Just copy bio_multi_split (might
> need to do some forward porting) and then modify linear_make_request to
> use bio_multi_split instead of bio_split.
>
> But I'm not really an expert on this particular code. I'm hoping someone
> else will confirm that this is in fact the bug and not a side effect of
> something else. Its seem reasonble that you could get a bio that is
> multi-page and falls on a boundary (spans two or more devices). So I
> suspect this is the bug.
>
> Regards,
> Mandeep
>
> > Regards,
> > Luzipher
> >
> >
> >
> > --- On Wed, 25/1/12, Mandeep Singh Baines <msb@xxxxxxxxxxxx> wrote:
> >
> > > From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
> > > Subject: Re: Kernel BUG (fs/bio.c:1499) when copying more files to an encrypted device
> > > To: "Luzipher McLeod" <luziphermcleod@xxxxxxxx>
> > > Cc: dm-crypt@xxxxxxxx, "NeilBrown" <neilb@xxxxxxx>
> > > Date: Wednesday, 25 January, 2012, 2:14
> > > Luzipher McLeod (luziphermcleod@xxxxxxxx)
> > > wrote:
> > > > Hi :-)
> > > >
> > > > A few days ago I encountered a kernel bug while copying
> > > files to an encrypted filesystem. The specific stack for the
> > > filesystem is: btrfs-on-crypt-on-mdraid. Vasts amounts of
> > > data copied without problems (about 6.3TB with 1.1 TB
> > > remaining), but when copying a certain directory, the kernel
> > > bug surfaces. I repeatedly deleted the affected directory
> > > and tried to re-copy it, but it always fails at the same
> > > point (or close to that). More recent test showed that I
> > > could copy a few more files to the filesystem to a different
> > > directory, but it very quickly failed there as well (a few
> > > megabytes later).
> > > > After talking to the btrfs devs on freenode (as btrfs
> > > is the most experimental thing in the stack, they came to
> > > the conclusion that it's most probably the crypto layer.
> > > >
> > > > Some details:
> > > > gentoo kernel 3.2.1 (custom config and ubuntu config)
> > > > mdraid: linear, 4 disks, each 2TB (total 8TB)
> > > > crypt: setup via cryptsetup -c aes-xts-plain64 -h plain
> > > -s 512 -d - create tempraid /dev/md/tempraid_lin
> > > >
> > > > I'd appreciate any help with this and would be happy to
> > > test patches or provide more debug info.
> > > >
> > > > Thanks and Regards,
> > > > Luzipher
> > > >
> > > >
> > > >
> > > >
> > > > The kernel bug output retrieved by netconsole (also at
> > > http://pastebin.com/sjJy7QE4 ):
> > > >? ???[? 294.538422] netconsole:
> > > local port 6666
> > > >? ???[? 333.423583] SysRq :
> > > Changing Loglevel
> > > >? ???[? 333.423609] Loglevel
> > > set to 9
> > > >? ???[? 424.248405]
> > > ------------[ cut here ]------------
> > > >? ???[? 424.248447] kernel BUG
> > > at fs/bio.c:1499!
> > >
> > > Hi Luzipher,
> > >
> > > Looks like the BUG is because bio_split only works on
> > > single-page iovecs.
> > >
> > > I see a relevant (old) patch from Neil Brown here:
> > >
> > > https://lkml.org/lkml/2007/7/30/496
> > >
> > > Regards,
> > > Mandeep
> > >
> >
------------------------------
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
End of dm-crypt Digest, Vol 31, Issue 24
****************************************
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
