LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "rubisher" <rubisher@scarlet.be>
To: "kyle" <kyle@mcmartin.ca>
Cc: "fujita\.tomonori" <fujita.tomonori@lab.ntt.co.jp>,
	"linux-kernel" <linux-kernel@vger.kernel.org>,
	"linux-parisc" <linux-parisc@vger.kernel.org>,
	"tomof" <tomof@acm.org>, "kyle" <kyle@parisc-linux.org>,
	"matthew" <matthew@wil.cx>,
	"grundler" <grundler@parisc-linux.org>,
	"akpm" <akpm@linux-foundation.org>,
	"rubisher" <rubisher@scarlet.be>
Subject: Re: [PATCH -mm 0/3] fix iommu segment boundary problems (parisc)
Date: Mon,  3 Mar 2008 12:04:00 +0100	[thread overview]
Message-ID: <JX5IQO$1ADFF18D173371DE06D03C11EFEA34BA@scarlet.be> (raw)

> On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> > This patchset is another sequel to my patchset to fix iommu segment
> > boundary problems, IOMMUs allocate memory areas without considering a
> > low level driver's segment boundary limits:
> > 
> > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg11919.html
> > 
> 
> This looks fine. Are you able to test this? If not, we can set you up
> with an account on a machine with remote console and all that jazz, if
> you'd like to.
> 
> cheers, Kyle
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Sorry for bad news but using a kernel known to work fine on my b2k (kyle's
parisc-2.6.git date 2008_02_21) against which I applied those patches, this
new kernel 32bit up failled to boot with this panic message:

Linux Tulip driver version 1.1.15 (Feb 27, 2007)
------------[ cut here ]------------
Kernel BUG at 1029520c [verbose debug info unavailable]

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110 Not tainted
r00-03  0004ff0e 1054c010 1029e774 80000000
r04-07  1fc2b020 00000100 00000000 00000001
r08-11  1fc1d454 1fc2c000 00000000 80000000
r12-15  00000001 00000001 1fc10858 0001a000
r16-19  00000011 104a23d0 00000000 ffffffff
r20-23  00001000 00000000 1fdb6a00 00000000
r24-27  00000000 00000001 00000100 10507010
r28-31  00000100 00100000 1fc205c0 00000000
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 1029520c 10295210
 IIR: 03ffe01f    ISR: 1024003f  IOR: 0802056c
 CPU:        0   CR30: 1fc20000 CR31: 11111111
 ORIG_R28: 0000000f
 IAOQ[0]: iommu_is_span_boundary+0x28/0x30
 IAOQ[1]: iommu_is_span_boundary+0x2c/0x30
 RP(r2): sba_alloc_range+0x23c/0x4f8
Backtrace:
 [<10107938>] show_regs+0x2c8/0x450
 [<10107c64>] die_if_kernel+0x98/0x1b0
 [<101083a0>] handle_interruption+0x624/0x6b4
 [<1010b078>] intr_check_sig+0x0/0x34
 [<1015d07c>] rmqueue_bulk+0x44/0x9c
 [<1015e778>] __alloc_pages+0xc4/0x388
 [<1015ea74>] __get_free_pages+0x38/0x74
 [<1029ed64>] sba_alloc_consistent+0x60/0xd4
 [<105852f0>] tulip_init_one+0x2ac/0xd10
 [<1029acb0>] pci_device_probe+0x70/0xa8
 [<102dad50>] driver_probe_device+0xa4/0x1bc
 [<102db01c>] __driver_attach+0x60/0xf4
 [<102da1dc>] bus_for_each_dev+0x58/0xa0
 [<102da978>] bus_add_driver+0xd4/0x1e0
 [<102db34c>] driver_register+0x48/0x108
 [<10565880>] kernel_init+0x120/0x33c

Backtrace:
 [<10107c6c>] die_if_kernel+0xa0/0x1b0
 [<101083a0>] handle_interruption+0x624/0x6b4
 [<1010b078>] intr_check_sig+0x0/0x34
 [<1015d07c>] rmqueue_bulk+0x44/0x9c
 [<1015e778>] __alloc_pages+0xc4/0x388
 [<1015ea74>] __get_free_pages+0x38/0x74
 [<1029ed64>] sba_alloc_consistent+0x60/0xd4
 [<105852f0>] tulip_init_one+0x2ac/0xd10
 [<1029acb0>] pci_device_probe+0x70/0xa8
 [<102dad50>] driver_probe_device+0xa4/0x1bc
 [<102db01c>] __driver_attach+0x60/0xf4
 [<102da1dc>] bus_for_each_dev+0x58/0xa0
 [<102da978>] bus_add_driver+0xd4/0x1e0
 [<102db34c>] driver_register+0x48/0x108
 [<10565880>] kernel_init+0x120/0x33c
 [<1010ac5c>] ret_from_kernel_thread+0x1c/0x24

Kernel panic - not syncing: Attempted to kill init!

(I haven't a lot a spare time right now, but I will do my best to help as much
as I can).

r.
---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/


             reply	other threads:[~2008-03-03 11:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-03 11:04 rubisher [this message]
2008-03-03 12:22 ` FUJITA Tomonori
  -- strict thread matches above, loose matches on Subject: below --
2008-03-04 16:13 rubisher
2008-03-05  2:56 ` FUJITA Tomonori
2008-03-03 14:43 rubisher
2008-03-03 10:36 rubisher
2008-03-02  6:10 FUJITA Tomonori
2008-03-02 17:13 ` Kyle McMartin
2008-03-05  3:54   ` FUJITA Tomonori
2008-03-05 15:45 ` Grant Grundler
2008-03-06  0:19   ` John David Anglin

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='JX5IQO$1ADFF18D173371DE06D03C11EFEA34BA@scarlet.be' \
    --to=rubisher@scarlet.be \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=grundler@parisc-linux.org \
    --cc=kyle@mcmartin.ca \
    --cc=kyle@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=tomof@acm.org \
    --subject='Re: [PATCH -mm 0/3] fix iommu segment boundary problems (parisc)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).