Re: 2.6.11-rc1-bk9 crash in mdadm
Lars Marowsky-Bree wrote: : On 2005-01-21T17:12:30, Jan Kasprzak <[EMAIL PROTECTED]> wrote: : : > Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9 : > kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now. : : Attached is a likely candidate for a fix. : : (It's been discussed on linux-raid already.) Yes, it makes 2.6.11-rc1-bk9 boot correctly on my box. Thanks! -Y. -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | > Whatever the Java applications and desktop dances may lead to, Unix will < > still be pushing the packets around for a quite a while. --Rob Pike < - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc1-bk9 crash in mdadm
On 2005-01-21T17:12:30, Jan Kasprzak <[EMAIL PROTECTED]> wrote:
> Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9
> kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now.
Attached is a likely candidate for a fix.
(It's been discussed on linux-raid already.)
Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
From: Jens Axboe <[EMAIL PROTECTED]>
Subject: Fix md using bio on stack with bio clones
Patch-mainline:
References: 49931
If md resides on top of a driver using bio_clone() (such as dm), it will
oops the kernel due to md submitting a botched bio that has a veclist but
doesn't have bio->bi_max_vecs set.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
= drivers/md/md.c 1.231 vs edited =
--- 1.231/drivers/md/md.c 2004-12-01 09:13:51 +01:00
+++ edited/drivers/md/md.c 2005-01-19 13:23:30 +01:00
@@ -332,29 +332,26 @@
static int sync_page_io(struct block_device *bdev, sector_t sector, int size,
struct page *page, int rw)
{
- struct bio bio;
- struct bio_vec vec;
+ struct bio *bio = bio_alloc(GFP_KERNEL, 1);
struct completion event;
+ int ret;
+
+ bio_get(bio);
rw |= (1 << BIO_RW_SYNC);
- bio_init();
- bio.bi_io_vec =
- vec.bv_page = page;
- vec.bv_len = size;
- vec.bv_offset = 0;
- bio.bi_vcnt = 1;
- bio.bi_idx = 0;
- bio.bi_size = size;
- bio.bi_bdev = bdev;
- bio.bi_sector = sector;
+ bio->bi_bdev = bdev;
+ bio->bi_sector = sector;
+ bio_add_page(bio, page, size, 0);
init_completion();
- bio.bi_private =
- bio.bi_end_io = bi_complete;
- submit_bio(rw, );
+ bio->bi_private =
+ bio->bi_end_io = bi_complete;
+ submit_bio(rw, bio);
wait_for_completion();
- return test_bit(BIO_UPTODATE, _flags);
+ ret = test_bit(BIO_UPTODATE, >bi_flags);
+ bio_put(bio);
+ return ret;
}
static int read_disk_sb(mdk_rdev_t * rdev)
2.6.11-rc1-bk9 crash in mdadm
Hi,
Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9
kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now.
-Yenya
Starting up RAID devices: md5 Unable to handle kernel NULL pointer dereference
at 0008 RIP:
{__make_request+61}
PGD f9f0f067 PUD fa01b067 PMD 0
Oops: [1] SMP
CPU 1
Modules linked in: floppy
Pid: 1632, comm: mdadm Not tainted 2.6.11-rc1-bk9
RIP: 0010:[] {__make_request+61}
RSP: 0018:8100f9f2b7f8 EFLAGS: 00010212
RAX: RBX: RCX: 810002d779c0
RDX: RSI: 8100f9f2b808 RDI: 81007ff8b2a8
RBP: 81007ff8b2a8 R08: 8100fae9b540 R09:
R10: 012a5200 R11: R12:
R13: 81007f4e4180 R14: 0008 R15: 8100f9f2bab8
FS: 2aab6b00() GS:804e9240() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 7f599000 CR4: 06e0
Process mdadm (pid: 1632, threadinfo 8100f9f2a000, task 81007f4036e0)
Stack: 012a523f 80151ca4 81007f4e4180 8100fae9b550
81007ff8b2a8 8100f9f2b878 81007f4e4180 81007feb6300
8100f9f2bab8 802e2a92
Call Trace:{mempool_alloc+164}
{generic_make_request+546}
{autoremove_wake_function+0}
{autoremove_wake_function+0}
{make_request+529}
{autoremove_wake_function+9}
{__wake_up_common+64}
{generic_make_request+546}
{autoremove_wake_function+0}
{md_open+112}
utoremove_wake_function+0} {submit_bio+280}
{sync_page_io+203} {bi_complete+0}
{read_disk_sb+83} {super_90_load+85}
{md_import_device+459}
{page_cache_readahead+490}
{radix_tree_delete+347}
{md_ioctl+3608}
{__pagevec_free+37}
{find_get_pages+107}
{blkdev_ioctl+1834}
{flat_send_IPI_allbutself+20}
{__smp_call_function+110}
{invalidate_bh_lru+0}
{bdev_clear_inode+28}
{wake_up_bit+24}
{do_ioctl+116} {sys_ioctl+881}
{system_call+126}
Code: 44 8b 7c 10 08 41 83 e4 01 e8 e5 9d e7 ff 48 8b bd f0 01 00
RIP {__make_request+61} RSP
CR2: 0008
/etc/rc.d/rc.sysinit: line 556: 1632 Killed /sbin/mdadm -Ac
partitions $i -m dev
Pid: 1632, comm: mdadm Not tainted 2.6.11-rc1-bk9
RIP: 0010:[] {__make_request+61}
RSP: 0018:8100f9f2b7f8 EFLAGS: 00010212
RAX: RBX: RCX: 810002d779c0
RDX: RSI: 8100f9f2b808 RDI: 81007ff8b2a8
RBP: 81007ff8b2a8 R08: 8100fae9b540 R09:
R10: 012a5200 R11: R12:
R13: 81007f4e4180 R14: 0008 R15: 8100f9f2bab8
FS: 2aab6b00() GS:804e9240() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 7f599000 CR4: 06e0
Process mdadm (pid: 1632, threadinfo 8100f9f2a000, task 81007f4036e0)
Stack: 012a523f 80151ca4 81007f4e4180 8100fae9b550
81007ff8b2a8 8100f9f2b878 81007f4e4180 81007feb6300
8100f9f2bab8 802e2a92
Call Trace:{mempool_alloc+164}
{generic_make_request+546}
{autoremove_wake_function+0}
{autoremove_wake_function+0}
{make_request+529}
{autoremove_wake_function+9}
{__wake_up_common+64}
{generic_make_request+546}
{autoremove_wake_function+0}
{md_open+112}
{autoremove_wake_function+0}
{submit_bio+280}
{sync_page_io+203} {bi_complete+0}
{read_disk_sb+83} {super_90_load+85}
{md_import_device+459}
{page_cache_readahead+490}
{radix_tree_delete+347}
{md_ioctl+3608}
{__pagevec_free+37}
{find_get_pages+107}
{blkdev_ioctl+1834}
{flat_send_IPI_allbutself+20}
{__smp_call_function+110}
{invalidate_bh_lru+0}
{bdev_clear_inode+28}
{wake_up_bit+24}
{do_ioctl+116} {sys_ioctl+881}
{system_call+126}
Code: 44 8b 7c 10 08 41 83 e4 01 e8 e5 9d e7 ff 48 8b bd f0 01 00
RIP {__make_request+61} RSP
CR2: 0008
/etc/rc.d/rc.sysinit: line 556: 1632 Killed /sbin/mdadm -Ac
partitions $i -m dev
--
| Jan "Yenya" Kasprzak |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while. --Rob Pike <
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc1-bk9 crash in mdadm
Hi,
Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9
kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now.
-Yenya
Starting up RAID devices: md5 Unable to handle kernel NULL pointer dereference
at 0008 RIP:
802e219d{__make_request+61}
PGD f9f0f067 PUD fa01b067 PMD 0
Oops: [1] SMP
CPU 1
Modules linked in: floppy
Pid: 1632, comm: mdadm Not tainted 2.6.11-rc1-bk9
RIP: 0010:[802e219d] 802e219d{__make_request+61}
RSP: 0018:8100f9f2b7f8 EFLAGS: 00010212
RAX: RBX: RCX: 810002d779c0
RDX: RSI: 8100f9f2b808 RDI: 81007ff8b2a8
RBP: 81007ff8b2a8 R08: 8100fae9b540 R09:
R10: 012a5200 R11: R12:
R13: 81007f4e4180 R14: 0008 R15: 8100f9f2bab8
FS: 2aab6b00() GS:804e9240() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 7f599000 CR4: 06e0
Process mdadm (pid: 1632, threadinfo 8100f9f2a000, task 81007f4036e0)
Stack: 012a523f 80151ca4 81007f4e4180 8100fae9b550
81007ff8b2a8 8100f9f2b878 81007f4e4180 81007feb6300
8100f9f2bab8 802e2a92
Call Trace:80151ca4{mempool_alloc+164}
802e2a92{generic_make_request+546}
80146050{autoremove_wake_function+0}
80146050{autoremove_wake_function+0}
803187e1{make_request+529}
80146059{autoremove_wake_function+9}
8012cd10{__wake_up_common+64}
802e2a92{generic_make_request+546}
80146050{autoremove_wake_function+0}
80320fc0{md_open+112}
utoremove_wake_function+0} 802e2bc8{submit_bio+280}
8031ea2b{sync_page_io+203} 8031e930{bi_complete+0}
8031f863{read_disk_sb+83} 8031fbf5{super_90_load+85}
8032060b{md_import_device+459}
80155bfa{page_cache_readahead+490}
8028cccb{radix_tree_delete+347}
803225d8{md_ioctl+3608}
80152ae5{__pagevec_free+37}
8014edfb{find_get_pages+107}
802e429a{blkdev_ioctl+1834}
80119434{flat_send_IPI_allbutself+20}
8011734e{__smp_call_function+110}
80173c90{invalidate_bh_lru+0}
80178fdc{bdev_clear_inode+28}
80146208{wake_up_bit+24}
801845d4{do_ioctl+116} 80184971{sys_ioctl+881}
8010d29e{system_call+126}
Code: 44 8b 7c 10 08 41 83 e4 01 e8 e5 9d e7 ff 48 8b bd f0 01 00
RIP 802e219d{__make_request+61} RSP 8100f9f2b7f8
CR2: 0008
/etc/rc.d/rc.sysinit: line 556: 1632 Killed /sbin/mdadm -Ac
partitions $i -m dev
Pid: 1632, comm: mdadm Not tainted 2.6.11-rc1-bk9
RIP: 0010:[802e219d] 802e219d{__make_request+61}
RSP: 0018:8100f9f2b7f8 EFLAGS: 00010212
RAX: RBX: RCX: 810002d779c0
RDX: RSI: 8100f9f2b808 RDI: 81007ff8b2a8
RBP: 81007ff8b2a8 R08: 8100fae9b540 R09:
R10: 012a5200 R11: R12:
R13: 81007f4e4180 R14: 0008 R15: 8100f9f2bab8
FS: 2aab6b00() GS:804e9240() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 7f599000 CR4: 06e0
Process mdadm (pid: 1632, threadinfo 8100f9f2a000, task 81007f4036e0)
Stack: 012a523f 80151ca4 81007f4e4180 8100fae9b550
81007ff8b2a8 8100f9f2b878 81007f4e4180 81007feb6300
8100f9f2bab8 802e2a92
Call Trace:80151ca4{mempool_alloc+164}
802e2a92{generic_make_request+546}
80146050{autoremove_wake_function+0}
80146050{autoremove_wake_function+0}
803187e1{make_request+529}
80146059{autoremove_wake_function+9}
8012cd10{__wake_up_common+64}
802e2a92{generic_make_request+546}
80146050{autoremove_wake_function+0}
80320fc0{md_open+112}
80146050{autoremove_wake_function+0}
802e2bc8{submit_bio+280}
8031ea2b{sync_page_io+203} 8031e930{bi_complete+0}
8031f863{read_disk_sb+83} 8031fbf5{super_90_load+85}
8032060b{md_import_device+459}
80155bfa{page_cache_readahead+490}
8028cccb{radix_tree_delete+347}
803225d8{md_ioctl+3608}
80152ae5{__pagevec_free+37}
8014edfb{find_get_pages+107}
802e429a{blkdev_ioctl+1834}
80119434{flat_send_IPI_allbutself+20}
8011734e{__smp_call_function+110}
80173c90{invalidate_bh_lru+0}
80178fdc{bdev_clear_inode+28}
Re: 2.6.11-rc1-bk9 crash in mdadm
On 2005-01-21T17:12:30, Jan Kasprzak [EMAIL PROTECTED] wrote:
Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9
kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now.
Attached is a likely candidate for a fix.
(It's been discussed on linux-raid already.)
Sincerely,
Lars Marowsky-Brée [EMAIL PROTECTED]
--
High Availability Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
From: Jens Axboe [EMAIL PROTECTED]
Subject: Fix md using bio on stack with bio clones
Patch-mainline:
References: 49931
If md resides on top of a driver using bio_clone() (such as dm), it will
oops the kernel due to md submitting a botched bio that has a veclist but
doesn't have bio-bi_max_vecs set.
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
= drivers/md/md.c 1.231 vs edited =
--- 1.231/drivers/md/md.c 2004-12-01 09:13:51 +01:00
+++ edited/drivers/md/md.c 2005-01-19 13:23:30 +01:00
@@ -332,29 +332,26 @@
static int sync_page_io(struct block_device *bdev, sector_t sector, int size,
struct page *page, int rw)
{
- struct bio bio;
- struct bio_vec vec;
+ struct bio *bio = bio_alloc(GFP_KERNEL, 1);
struct completion event;
+ int ret;
+
+ bio_get(bio);
rw |= (1 BIO_RW_SYNC);
- bio_init(bio);
- bio.bi_io_vec = vec;
- vec.bv_page = page;
- vec.bv_len = size;
- vec.bv_offset = 0;
- bio.bi_vcnt = 1;
- bio.bi_idx = 0;
- bio.bi_size = size;
- bio.bi_bdev = bdev;
- bio.bi_sector = sector;
+ bio-bi_bdev = bdev;
+ bio-bi_sector = sector;
+ bio_add_page(bio, page, size, 0);
init_completion(event);
- bio.bi_private = event;
- bio.bi_end_io = bi_complete;
- submit_bio(rw, bio);
+ bio-bi_private = event;
+ bio-bi_end_io = bi_complete;
+ submit_bio(rw, bio);
wait_for_completion(event);
- return test_bit(BIO_UPTODATE, bio.bi_flags);
+ ret = test_bit(BIO_UPTODATE, bio-bi_flags);
+ bio_put(bio);
+ return ret;
}
static int read_disk_sb(mdk_rdev_t * rdev)
Re: 2.6.11-rc1-bk9 crash in mdadm
Lars Marowsky-Bree wrote:
: On 2005-01-21T17:12:30, Jan Kasprzak [EMAIL PROTECTED] wrote:
:
: Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9
: kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now.
:
: Attached is a likely candidate for a fix.
:
: (It's been discussed on linux-raid already.)
Yes, it makes 2.6.11-rc1-bk9 boot correctly on my box. Thanks!
-Y.
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
Whatever the Java applications and desktop dances may lead to, Unix will
still be pushing the packets around for a quite a while. --Rob Pike
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
