All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Joel Soete" <soete.joel@tiscali.be>
To: "List Parisc" <parisc-linux@lists.parisc-linux.org>
Cc: willy@debian.org, James.Bottomley@steeleye.com,
	grundler@parisc-linux.org
Subject: [parisc-linux] Re: NCR53c720
Date: Tue, 4 May 2004 09:22:50 +0200	[thread overview]
Message-ID: <408D439D00004F55@ocpmta3.freegates.net> (raw)

Hello all,

There was a thread:: <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-September/021172.html>

which would help me to find the right direction to solve this pb:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2004-April/022968.html>

The only new think I discover became when I reboot a kernel build with gcc-3.0:
[snip]
: arq->state 2
Badness in as_requeue_request at drivers/block/as-iosched.c:1479
Kernel addresses on the stack:
 [<10127830>] printk+0x12c/0x1b0
 [<10107d64>] dump_stack+0x18/0x24
 [<1022b21c>] as_requeue_request+0x64/0x108
 [<102225c0>] elv_requeue_request+0x3c/0x64
 [<102250a8>] blk_insert_request+0x4c/0xf8
 [<1024f418>] scsi_queue_insert+0x6c/0xa0
 [<102642d8>] ncr_wakeup_done+0x90/0xc0
 [<1024b578>] scsi_softirq+0xcc/0x128
 [<1024b498>] scsi_done+0x5c/0x70
 [<1012b504>] __do_softirq+0x60/0xcc
 [<10109428>] do_irq+0xa4/0x160
 [<1010231c>] __scheduling_functions_end_here+0x3c/0x48
 [<10109574>] do_cpu_irq_mask+0x90/0xf0
 [<1010d068>] intr_return+0x0/0x14
 [<102632a4>] ncr_start_next_ccb+0xdc/0x104
 [<10145e6c>] kmem_cache_alloc+0x3c/0x4c
 [<1015d69c>] get_empty_filp+0x64/0x11c
 [<1015bc80>] dentry_open+0x12c/0x1b4
 [<1016f8b0>] locate_fd+0xfc/0x190
 [<10145e64>] kmem_cache_alloc+0x34/0x4c
 [<10140530>] mempool_alloc+0xac/0x184
 [<10225fcc>] generic_make_request+0x15c/0x1fc
 [<101ab458>] __journal_remove_journal_head+0x144/0x1e4
 [<10162b28>] bio_alloc+0x14c/0x1bc
 [<102260e0>] submit_bio+0x74/0x154
 [<10162234>] submit_bh+0x8c/0x16c
 [<10162388>] ll_rw_block+0x74/0x140
 [<101a6fc4>] journal_brelse_array+0x2c/0x44
 [<101a6f04>] journal_commit_transaction+0xfdc/0x1070
 [<101ee0cc>] vsnprintf+0x6a4/0x8cc
 [<101a94ac>] kjournald+0xc8/0x220
 [<1015cb58>] sys_write+0x4c/0x84
 [<10129b34>] do_group_exit+0x84/0xbc
 [<1010a35c>] tracesys_exit+0x0/0x34
 [<1010cc5c>] ret_from_kernel_thread+0x1c/0x24

kernel BUG at include/linux/blkdev.h:562!
Kernel addresses on the stack:
 [<10127830>] printk+0x12c/0x1b0
 [<10107d64>] dump_stack+0x18/0x24
 [<10250630>] scsi_request_fn+0x2b4/0x388
 [<102225c0>] elv_requeue_request+0x3c/0x64
 [<10225110>] blk_insert_request+0xb4/0xf8
 [<1024f418>] scsi_queue_insert+0x6c/0xa0
 [<102642d8>] ncr_wakeup_done+0x90/0xc0
 [<1024b578>] scsi_softirq+0xcc/0x128
 [<1024b498>] scsi_done+0x5c/0x70
 [<1012b504>] __do_softirq+0x60/0xcc
 [<10109428>] do_irq+0xa4/0x160
 [<1010231c>] __scheduling_functions_end_here+0x3c/0x48
 [<10109574>] do_cpu_irq_mask+0x90/0xf0
 [<1010d068>] intr_return+0x0/0x14
 [<102632a4>] ncr_start_next_ccb+0xdc/0x104
 [<10145e6c>] kmem_cache_alloc+0x3c/0x4c
 [<1015d69c>] get_empty_filp+0x64/0x11c
 [<1015bc80>] dentry_open+0x12c/0x1b4
 [<1016f8b0>] locate_fd+0xfc/0x190
 [<10145e64>] kmem_cache_alloc+0x34/0x4c
 [<10140530>] mempool_alloc+0xac/0x184
 [<10225fcc>] generic_make_request+0x15c/0x1fc
 [<101ab458>] __journal_remove_journal_head+0x144/0x1e4
 [<10162b28>] bio_alloc+0x14c/0x1bc
 [<102260e0>] submit_bio+0x74/0x154
 [<10162234>] submit_bh+0x8c/0x16c
 [<10162388>] ll_rw_block+0x74/0x140
 [<101a6fc4>] journal_brelse_array+0x2c/0x44
 [<101a6f04>] journal_commit_transaction+0xfdc/0x1070
 [<101ee0cc>] vsnprintf+0x6a4/0x8cc
 [<101a94ac>] kjournald+0xc8/0x220
 [<1015cb58>] sys_write+0x4c/0x84
 [<10129b34>] do_group_exit+0x84/0xbc
 [<1010a35c>] tracesys_exit+0x0/0x34
 [<1010cc5c>] ret_from_kernel_thread+0x1c/0x24

[snip]

which makes appear ncr_wakeup_done() and ncr_start_next_ccb() but I don't
yet reach to figure out why the work-around which consist of commenting 'parisc_vmerge_max_size
= ...' into ccio-dma.c make the stuff working (that just let parisc_vmerge_max_size
=0 as initialized in gsc.c)

I also try to compare ncr_start_next_ccb with its sister sym_ and discover
that there was a improved way to manage requeing but I don't find how to
manage such changes (new ncr53720 files, a sym53c7xx_2 tree, ...). 

Any idea?

Thanks for yoyr attention,
    Joel

----------------------------------------------------------------------------------------
Tiscali ADSL, 27,50 €/mois...pendant 6 mois. 
La meilleure offre du marché !
http://reg.tiscali.be/default.asp?lg=fr

             reply	other threads:[~2004-05-04  7:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-04  7:22 Joel Soete [this message]
     [not found] <Pine.GSO.4.21.0309291116250.7432-100000@vervain.sonytel.be>
     [not found] ` <Pine.LNX.4.44.0309291434260.17812-100000@serv>
2003-09-29 13:33   ` [parisc-linux] Re: NCR53c720 Matthew Wilcox
2003-09-29 13:45     ` Geert Uytterhoeven
2003-09-29 16:24     ` Roman Zippel
2003-09-29 16:27       ` Matthew Wilcox
2003-09-29 20:55         ` Grant Grundler
2003-09-29 21:00           ` James Bottomley
2003-09-30 17:23             ` Grant Grundler
2003-09-29 21:25     ` Rene Brothuhn
2003-09-30  2:21       ` Matthew Wilcox
2003-09-30  8:21         ` Geert Uytterhoeven
2003-09-30 13:47           ` James Bottomley
2003-09-30 13:59             ` Matthew Wilcox
2003-09-30 15:32               ` James Bottomley
2003-09-30 19:03                 ` Grant Grundler
2003-09-30 13:59         ` Rene Brothuhn
2003-09-30 14:32           ` Matthew Wilcox
2003-10-07 20:22             ` Rene Brothuhn
2003-09-30 14:55           ` Roman Zippel
2003-10-07 20:24             ` Rene Brothuhn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=408D439D00004F55@ocpmta3.freegates.net \
    --to=soete.joel@tiscali.be \
    --cc=James.Bottomley@steeleye.com \
    --cc=grundler@parisc-linux.org \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.