All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)
Date: Sun, 12 Mar 2006 14:26:16 +0100	[thread overview]
Message-ID: <200603121426.16996.deller@gmx.de> (raw)
In-Reply-To: <20060308073743.GA31959@colo.lackof.org>

On Wednesday 08 March 2006 08:37, Grant Grundler wrote:
> On Tue, Mar 07, 2006 at 10:27:37PM +0100, Helge Deller wrote:
> > Attached is the patch.
> > I still think we should try to get real ioremapping working.
> > I'm no Linux-Kernel-memory-expert, but my plan was to read about it and learn.
> > Currently, if I enable CONFIG_HPPA_IOREMAP the 64bit kernel crashes
> > in sba_iommu.c: sba_driver_callback() after the first ioremap().
> > Maybe others here want to try as well ?
> 
> Yes, I have. It crashed in exactly the same location.
> But I don't understand the VM magic needed to make this work either.

I did some more testing and analysis on this problem.
(I even for the first time did some reading on Linux kernel memory management to understand all that pgd, pmd, pte stuff :-))

Here is my current analysis.
Maybe someone with a better understanding might have some idea on what's going on ?

drivers/parisc/sba_iommu.c does the following on my machine:
        void __iomem *sba_addr;
        sba_addr = ioremap(0xfffffffffed00000, 4096);  /* 0xfffffffffed00000 is hpa of Astro BC Runway Port at 0xfffffffffed00000 [10] */
        func_class = * (volatile unsigned long long *) (sba_addr + 8);

Here is the important part of the bootlog:

Linux version 2.6.16-rc5-pa2 (root@p100) (gcc version 3.4.3) #21 Sun Mar 12 13:43:30 CET 2006
FP[0] enabled: Rev 1 Model 19
The 64-bit Kernel has started...
Found devices:
1. Astro BC Runway Port at 0xfffffffffed00000 [10] { 12, 0x0, 0x582, 0x0000b }
2. Elroy PCI Bridge at 0xfffffffffed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
3. Elroy PCI Bridge at 0xfffffffffed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
4. Elroy PCI Bridge at 0xfffffffffed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
5. Elroy PCI Bridge at 0xfffffffffed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
6. Allegro W2 at 0xfffffffffffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
7. Memory at 0xfffffffffed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 3ba6c0 (1 CPUs online)

hpa start = fffffffffed00000 size=4096    <<<<<< this is the Astro BC
IOREMAP: phys_addr=fffffffffed00000, offset = 0, size=4096
IOREMAP: addr = 0000000000008000         <<<<< the new vm area ( fffffffffed00000(phys) will be mapped to 0x8000(virt))
set_pte: virtual:8000 -> phys=fffffffffed00000, pte=fffffffffed00283  << here is the pte entry which ioremap() generates.

The pte value seems right, and the __pgprot flags which I used were: _PAGE_PRESENT | _PAGE_RW | _PAGE_NO_CACHE;

So, in my opinion, ioremap() does technically the right thing.
Nevertheless, when reading the quadword from (virt) 0x8000+8 it crashes ("A Data Miss Timeout"? - see HPMC log).

Below is the PIM HPMC output.
Looking at the log, it seems that the pte was (mostly?) right, since
the System Responder Address below is 0xfffffffffed10200.
Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ?

Any ideas ?

Helge

-----------------  Processor 0 HPMC Information ------------------
Timestamp =
  Sun Mar  12 13:12:54 GMT 2006    (20:06:03:12:13:12:54)

HPMC Chassis Codes = 2cbf0  2500b  2cbf4  2cbfc

General Registers 0 - 31
00-03   0000000000000000  0000000010604920  000000001027a738  000000008fc4a400
04-07   0000000010601920  0000000010576690  0000000000008000  00000000105766b8
08-11   0000000010673380  0000000000000000  000f41fa3d8dea40  00000000105673a8
12-15   000000003b9aca00  00000000ffffffff  0000000000000000  00000000f0400004
16-19   000000008fc4a400  00000000f000017c  00000000f0000174  0000000010567b50
20-23   0000000000000000  0000000000000001  000000000000093c  000000000067123c
24-27   ffffffffffffffff  0000000000000001  0000000010567b50  0000000010601920
28-31   0000000000000018  000000008fc24b30  000000008fc24890  0000000000000060

Control Registers 0 - 31
00-03   0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07   0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11   0000000000000000  0000000000000000  00000000000000c0  0000000000000024
12-15   0000000000000000  0000000000000000  0000000000103000  8000000000000000
16-19   00000009653d8c30  0000000000000000  000000001027a738  000000000cd010d3
20-23   000000000035fffb  0000000040008008  000000000804000f  8000000000000000
24-27   000000000055d000  000000000055d000  00000000ffffffff  00000000ffffffff
28-31   00000000ffffffff  00000000ffffffff  000000008fc24000  00000000105b4000
Space Registers 0 - 7

00-03   00000000          00000000          00000000          00000000
04-07   00000000          00000000          00000000          00000000

IIA Space                    = 0x0000000000000000
IIA Offset                   = 0x000000001027a73c
Check Type                   = 0x20000000
CPU State                    = 0x9e000004
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x003010bb
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00031800
System Responder Address     = 0xfffffffffed10200
System Requestor Address     = 0xfffffffffffa0000

'9000/785 B,C,J Workstation Unarchitected (per-CPU)', rev 1, 140 bytes:

Check Summary                = 0xcb81041000000000
Available Memory             = 0x0000000080000000
CPU Diagnose Register 2      = 0x0301000000802004
CPU Status Register 0        = 0x2020c20000000000
CPU Status Register 1        = 0x8080000000000000
SADD LOG                     = 0x2b0a10000fc212c1
Read Short LOG               = 0xc18040fffee003fd
ERROR_STATUS                 = 0x0000000000000010
MEM_ADDR                     = 0x000001ff3fffffff
MEM_SYND                     = 0x0000000000000000
MEM_ADDR_CORR                = 0x000001ff3fffffff
MEM_SYND_CORR                = 0x0000000000000000
RUN_DATA_HIGH                = 0xc1bff0fffed08040
RUN_DATA_LOW                 = 0xc1bff0fffed08040
RUN_CTRL                     = 0x0000021c00002a1c
RUN_ADDR                     = 0xc1bff0fffed08040
System Responder Path        = 0x00ffffffffffffff

HPMC PIM Analysis Information:
Timestamp =
  Sun Mar  12 13:12:54 GMT 2006    (20:06:03:12:13:12:54)
'9000/785 B,C,J Workstation HPMC PIM Analysis (per-CPU)', rev 0, 1304 bytes:

A Data Miss Timeout occurred while CPU 0 was
requesting information.


Memory/IO Controller Error Analysis Information:

The Memory/IO Controller only observed the Broadcast Error.  It did not log
any additional information about the HPMC.

Memory Error Log Information:
Timestamp =
  Sun Mar  12 13:12:54 GMT 2006    (20:06:03:12:13:12:54)

'9000/785 B,C,J Workstation Memory Error Log', rev 0, 64 bytes:

   No memory errors logged

I/O Module Error Log Information:
Timestamp =
  Sun Mar  12 13:12:54 GMT 2006    (20:06:03:12:13:12:54)

'9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes:

 Rope     Word1        Word2            Word3
------ ------------ ------------
   0    0x00000000   0x0e0cc009   0x00000000fed30048
   1    0x00000000   0x1e0cc009   0x00000000fed32048
   2    ----------   0x2e0cc009   ------------------
   3    ----------   0x3e0cc009   ------------------
   4    0x00000000   0x4e0cc009   0x00000000fed38048
   5    ----------   0x5e0cc009   ------------------
   6    0x00000000   0x6e0cc009   0x00000000fed3c048
   7    ----------   0x7e0cc009   ------------------
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

       reply	other threads:[~2006-03-12 13:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060307211213.3A261494013@palinux.hppa>
     [not found] ` <200603072227.38097.deller@gmx.de>
     [not found]   ` <20060308073743.GA31959@colo.lackof.org>
2006-03-12 13:26     ` Helge Deller [this message]
2006-03-13 20:34       ` [parisc-linux] Re: linux-2.6 deller (ioremap-changes) Grant Grundler
2006-03-15  7:20       ` [parisc-linux] ioremap-changes Grant Grundler
2006-03-17 17:27       ` [parisc-linux] Re: linux-2.6 deller (ioremap-changes) Grant Grundler
2006-03-21 23:09         ` Helge Deller
2006-03-22  3:52           ` Kyle McMartin
2006-03-22 17:18 Joel Soete
2006-03-22 18:16 ` Helge Deller
2006-03-22 22:30   ` Helge Deller
2006-03-22 23:49     ` John David Anglin
2006-03-23  6:46       ` Helge Deller
2006-03-26  1:45         ` John David Anglin
2006-03-26  5:45           ` Grant Grundler
2006-03-26 10:06             ` Joel Soete
2006-05-06 22:44       ` John David Anglin
  -- strict thread matches above, loose matches on Subject: below --
2006-03-23  6:17 Joel Soete
2006-03-23  8:38 Joel Soete
2006-03-23 13:54 ` John David Anglin
2006-03-23 18:07   ` Helge Deller

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=200603121426.16996.deller@gmx.de \
    --to=deller@gmx.de \
    --cc=parisc-linux@lists.parisc-linux.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.