[parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Helge Deller]

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

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Grant Grundler]

On Sun, Mar 12, 2006 at 02:26:16PM +0100, Helge Deller wrote:
> Here is my current analysis.
> Maybe someone with a better understanding might have some idea on what's going on ?

Yes - I'll take another look. You have good data below:

> 1. Astro BC Runway Port at 0xfffffffffed00000 [10] { 12, 0x0, 0x582, 0x0000b }
...
> hpa start = fffffffffed00000 size=4096    <<<<<< this is the Astro BC
> IOREMAP: phys_addr=fffffffffed00000, offset = 0, size=4096

I think we ahould be doing an ioremap of HPA + ASTRO_IOC_OFFSET.
ie 32*4k (0x20000)

> 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.
...
> 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 ?

We need to map the BC port to get rev info and we do that
at the top of sba_driver_callback(). So I _think_ the first
accesses are working.

Later, sba_ioc_init() calls
	sba_dev->ioc[0].ioc_hpa = ioc_remap(sba_dev, ASTRO_IOC_OFFSET);

That looks fine too.

I just wonder why we are accessing 0xfffffffffed10200 (ioc? + ROPE0_CTL)
instead of (BC HPA + 32 * SBA_FUNC_SIZE):
	0xfffffffffed00000 + 32 * 4K = 0xfffffffffed20000

Maybe the offset isn't being placed into the page table correctly.
(Unlikely...)


> Any ideas ?

I'll keep looking more later today and/or tomorrow.
I want to review the HPMC data again too.

thanks,
grant

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Grant Grundler]

On Sun, Mar 12, 2006 at 02:26:16PM +0100, Helge Deller wrote:
> Here is the important part of the bootlog:
...
> 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

I'm wondering if we want all 64 bits set in the pte or if we only want
to set the lower 40 (or 44 for pa8800) bits. The Astro system map
only shows 40-bits.

The "f_extend" might not be needed for Astro chipset if the HW will
automatically alias the 32-bit address range for us. The address
map doesn't indicate 4GB-256MB is aliased. But I wonder how the
32-bit OS could otherwise work - unless PA20 CPU is silently
sign extending everything for us.

Hrm...suggests that maybe we are doing something wrong in the
asm for the 64-bit case.

> Nevertheless, when reading the quadword from (virt) 0x8000+8 it crashes
> ("A Data Miss Timeout"? - see HPMC log).

> Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ?

As noted before, this is a quirk in the firmware - fed10200 is the memory
controller.

> -----------------  Processor 0 HPMC Information ------------------
...
> MEM_ADDR                     = 0x000001ff3fffffff

~0UL means not valid.

> RUN_ADDR                     = 0xc1bff0fffed08040

This was the last Runway address seen on the bus.
Ditto for RUN_DATA_HIGH/LOW.

Unfortunately, fffed08040 is the address of RUN_ADDR register.
It suggests the memory controller never saw an error
and continued recording until HPMC code reads RUN_ADDR.

hth,
grant

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Helge Deller]

Hi all,

it turned out, that it was a stupid bug in the PFN calculation of the DTLB handler routine.
It's fixed now in CVS.
The 64bit Kernel boots now, but I still have to clean up STIfb driver to do the right thing.

Anyway, nice to have this fixed.
If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option.

Helge

On Friday 17 March 2006 18:27, Grant Grundler wrote:
> On Sun, Mar 12, 2006 at 02:26:16PM +0100, Helge Deller wrote:
> > Here is the important part of the bootlog:
> ...
> > 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
> 
> I'm wondering if we want all 64 bits set in the pte or if we only want
> to set the lower 40 (or 44 for pa8800) bits. The Astro system map
> only shows 40-bits.
> 
> The "f_extend" might not be needed for Astro chipset if the HW will
> automatically alias the 32-bit address range for us. The address
> map doesn't indicate 4GB-256MB is aliased. But I wonder how the
> 32-bit OS could otherwise work - unless PA20 CPU is silently
> sign extending everything for us.
> 
> Hrm...suggests that maybe we are doing something wrong in the
> asm for the 64-bit case.
> 
> > Nevertheless, when reading the quadword from (virt) 0x8000+8 it crashes
> > ("A Data Miss Timeout"? - see HPMC log).
> 
> > Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ?
> 
> As noted before, this is a quirk in the firmware - fed10200 is the memory
> controller.
> 
> > -----------------  Processor 0 HPMC Information ------------------
> ...
> > MEM_ADDR                     = 0x000001ff3fffffff
> 
> ~0UL means not valid.
> 
> > RUN_ADDR                     = 0xc1bff0fffed08040
> 
> This was the last Runway address seen on the bus.
> Ditto for RUN_DATA_HIGH/LOW.
> 
> Unfortunately, fffed08040 is the address of RUN_ADDR register.
> It suggests the memory controller never saw an error
> and continued recording until HPMC code reads RUN_ADDR.
> 
> hth,
> grant
> 
> 
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Kyle McMartin]

On Wed, Mar 22, 2006 at 12:09:43AM +0100, Helge Deller wrote:
> it turned out, that it was a stupid bug in the PFN calculation of the DTLB handler routine.
> It's fixed now in CVS.
> The 64bit Kernel boots now, but I still have to clean up STIfb driver to do the right thing.
>

Wow, way to go! 

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Joel Soete]

> Hi all,
> 
> it turned out, that it was a stupid bug in the PFN calculation of the D=
TLB
handler routine.
> It's fixed now in CVS.
> The 64bit Kernel boots now, but I still have to clean up STIfb driver t=
o do
the right thing.
> 
> Anyway, nice to have this fixed.
> If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option.
> 
Great job ;-)

Tested on n4k (2 way 64bit kernel) and all seems to works fine.

But unfortuantely failed to boot on b2k (64bit up kernel):
Soft power switch enabled, polling @ 0xfffffff0f0400804.                 =
    
                                                      
STI GSC/PCI core graphics driver Version 0.9a                            =
    
                                                      
STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb0=
00000
(16 MB)                                              
    id 35acda16-9a02587, conforms to spec rev. 8.0c                      =
    
                                                      
BUG: soft lockup detected on CPU#0!                                      =
    
                                                      
                                                                         =
    
                                                      
     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI                                    =
    
                                                      
PSW: 00001000000001000000000000001111 Not tainted                        =
    
                                                      
r00-03  0000000000000000 0000000000000080 000000001010a908 00000000800000=
00  
                                                      
r04-07  000000000000002a 00000000a8000000 0000000000000555 00000000000000=
0d  
                                                      
r08-11  0000000000000000 0000000090dc4f6c 0000000000000001 0000000010dc51=
c8  
                                                      
r12-15  0000000000000010 0000000000000010 0000000000000001 ffffffffffffff=
ff  
                                                      
r16-19  000000001043b328 0000000000000000 0000000000000000 00000000000000=
00  
                                                      
r20-23  0000000000000000 0000000000000000 0000000000000005 00000000000080=
00  
                                                      
r24-27  0000000000000000 0000000000008000 00000000000000cc 00000000105cbc=
40  
                                                      
r28-31  0000000000000000 00000000002aa800 0000000010dc5390 00000000002aa8=
00  
                                                      
sr0-3   0000000000000000 0000000000000000 0000000000000000 00000000000000=
00  
                                                      
sr4-7   0000000000000000 0000000000000000 0000000000000000 00000000000000=
00  
                                                      
                                                                         =
    
                                                      
      VZOUICununcqcqcqcqcqcrmunTDVZOUI                                   =
    
                                                      
FPSR: 00000100000100000000100000000000                                   =
    
                                                      
FPER1: 24850e06                                                          =
    
                                                      
fr00-03  0000000000000000 0000001f00000000 0000001f00000000 0000001f00000=
000 
                                                      
fr04-07  0000000000000000 5555555555555555 5555555555555555 5555555555555=
555 
                                                      
fr08-11  5555555555555555 5555555555555555 5555555555555555 5555555555555=
555 
                                                      
fr12-15  5555555555555555 5555555555555555 5555555555555555 5555555555555=
555 
                                                      
fr16-19  5555555555555555 5555555555555555 5555555555555555 5555555555555=
555 
                                                      
fr20-23  5555555555555555 5555555555555555 0000000000000000 0000000000000=
000 
                                                      
fr24-27  0000000000000000 5555555555555555 5555555555555555 5555555555555=
555 
                                                      
fr28-31  5555555555555555 5555555555555555 5555555555555555 5555555555555=
555 
                                                      
                                                                         =
    
                                                      
IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000102a3cd8
00000000102a3cdc                                                     
 IIR: d3bd1ae8    ISR: 0000000000000000  IOR: 00000000105cbc40           =
    
                                                      
 CPU:        0   CR30: 0000000010dc4000 CR31: 0000000010584000           =
    
                                                      
 ORIG_R28: 00000000104bd008                                              =
    
                                                      
 IAOQ[0]: memset+0x378/0x8e0                                             =
    
                                                      
 IAOQ[1]: memset+0x37c/0x8e0                                             =
    
                                                      
 RP(r2): __udivdi3+0x518/0x940

(which same 32bit kernel seems to works fine?)

Thanks,
    Joel

PS: on going to test on d380 (will advise later)
=0A=0A-------------------------------------------------------=0ANOTE! My =
email address is changing to ... @scarlet.be=0APlease make the necessary =
changes in your address book. =0A=0A

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Helge Deller]

On Wednesday 22 March 2006 18:18, Joel Soete wrote:
> > The 64bit Kernel boots now, but I still have to clean up STIfb driver to 
> > do the right thing.
> > Anyway, nice to have this fixed.
> > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option.
> 
> But unfortuantely failed to boot on b2k (64bit up kernel):
> STI GSC/PCI core graphics driver Version 0.9a                                
> STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb000000
> (16 MB)                                              
>     id 35acda16-9a02587, conforms to spec rev. 8.0c                          
> BUG: soft lockup detected on CPU#0!                                          
> <crash>

That's why I said I need to fix STIfb.... :-)

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Helge Deller]

On Wednesday 22 March 2006 19:16, Helge Deller wrote:
> On Wednesday 22 March 2006 18:18, Joel Soete wrote:
> > > The 64bit Kernel boots now, but I still have to clean up STIfb driver to 
> > > do the right thing.
> > > Anyway, nice to have this fixed.
> > > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option.
> > 
> > But unfortuantely failed to boot on b2k (64bit up kernel):
> > STI GSC/PCI core graphics driver Version 0.9a                                
> > STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb000000
> > (16 MB)                                              
> >     id 35acda16-9a02587, conforms to spec rev. 8.0c                          
> > BUG: soft lockup detected on CPU#0!                                          
> > <crash>
> 
> That's why I said I need to fix STIfb.... :-)

It's fixed now in CVS (2.6.16-pa2).
Even X11 on stifb with 64bit kernel works...

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[John David Anglin]

> > That's why I said I need to fix STIfb.... :-)
> 
> It's fixed now in CVS (2.6.16-pa2).
> Even X11 on stifb with 64bit kernel works...

Did this bug also affect 32bit kernels?  The reason I ask is I
had to back out using 2.6.16-pa0 on my c3k.  The most obvious
symptoms were fsck failures on reboot, iptables error messages
and unreliable behavior of gnome teminal.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Joel Soete]

> On Wednesday 22 March 2006 19:16, Helge Deller wrote:
> > On Wednesday 22 March 2006 18:18, Joel Soete wrote:
> > > > The 64bit Kernel boots now, but I still have to clean up STIfb dr=
iver to 
> > > > do the right thing.
> > > > Anyway, nice to have this fixed.
> > > > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP opt=
ion.
> > > 
> > > But unfortuantely failed to boot on b2k (64bit up kernel):
> > > STI GSC/PCI core graphics driver Version 0.9a                      =
    
     
> > > STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at
fffffffffb000000
> > > (16 MB)                                              
> > >     id 35acda16-9a02587, conforms to spec rev. 8.0c                =
    
     
> > > BUG: soft lockup detected on CPU#0!                                =
    
     
> > > <crash>
> > 
> > That's why I said I need to fix STIfb.... :-)
> 
Appologies for my bad understanding of your previous advise ;-)

> It's fixed now in CVS (2.6.16-pa2).
> Even X11 on stifb with 64bit kernel works...
> 
Great I will test asap.

Thanks a lot,
    Joel=0A=0A-------------------------------------------------------=0AN=
OTE! My email address is changing to ... @scarlet.be=0APlease make the ne=
cessary changes in your address book. =0A=0A

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Helge Deller]

On Thursday 23 March 2006 00:49, John David Anglin wrote:
> > > That's why I said I need to fix STIfb.... :-)
> > 
> > It's fixed now in CVS (2.6.16-pa2).
> > Even X11 on stifb with 64bit kernel works...
> 
> Did this bug also affect 32bit kernels?  The reason I ask is I
> had to back out using 2.6.16-pa0 on my c3k.  The most obvious
> symptoms were fsck failures on reboot, iptables error messages
> and unreliable behavior of gnome teminal.

The fixes I did was only related to virtually-mapped vs. physically-addressed memory regions.
So I don't think I changed anything special for a 32bit kernel if you didn't set CONFIG_HPPA_IOREMAP.

But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it worked fine, so I assume you shouldn't see any problems either...

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Joel Soete]

> On Thursday 23 March 2006 00:49, John David Anglin wrote:
> > > > That's why I said I need to fix STIfb.... :-)
> > > 
> > > It's fixed now in CVS (2.6.16-pa2).
> > > Even X11 on stifb with 64bit kernel works...
> > 
> > Did this bug also affect 32bit kernels?  The reason I ask is I
> > had to back out using 2.6.16-pa0 on my c3k.  The most obvious
> > symptoms were fsck failures on reboot, iptables error messages
> > and unreliable behavior of gnome teminal.
> 
> The fixes I did was only related to virtually-mapped vs.
physically-addressed memory regions.
> So I don't think I changed anything special for a 32bit kernel if you d=
idn't
set CONFIG_HPPA_IOREMAP.
> 
> But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it=

worked fine, so I assume you shouldn't see any problems either...
> 
mmm, just about gnome (i don't yet tested iptables) since midle of last d=
ec,
after an apt-get dist-upgrade, sudenly many gnome based app (firefox,
gftp-gtk, d4x, gnome-terminal, ...) running on a debian unstable _i386_ d=
id
segv (not yet fixed ;-( ). Fwiw, this seems to be an 'orphan' pb (i.e. ra=
re):
for me it only occures when the X server is the one of hpux-1100 and not =
with
another linux one (iirc X.org) (or even the solaris one :/).
Otoh, that give me the opportunity to test kde brotherhood tools (even
konqueror ;-) runing fine with a Ubuntu (drapper) installed actualy as a
vserver on my d380.

Hth,
    Joel
  =0A=0A---------------------------------------------------------------=0A=
A free anti-spam and anti-virus filter on all Scarlet mailboxes=0AMore in=
fo on http://www.scarlet.be/

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[John David Anglin]

> > But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it
> worked fine, so I assume you shouldn't see any problems either...
> > 
> mmm, just about gnome (i don't yet tested iptables) since midle of last dec,
> after an apt-get dist-upgrade, sudenly many gnome based app (firefox,
> gftp-gtk, d4x, gnome-terminal, ...) running on a debian unstable _i386_ did
> segv (not yet fixed ;-( ). Fwiw, this seems to be an 'orphan' pb (i.e. rare):
> for me it only occures when the X server is the one of hpux-1100 and not with
> another linux one (iirc X.org) (or even the solaris one :/).
> Otoh, that give me the opportunity to test kde brotherhood tools (even
> konqueror ;-) runing fine with a Ubuntu (drapper) installed actualy as a
> vserver on my d380.

Generally, I prefer kde but it hasn't been installable on unstable for
several months:

The following packages have unmet dependencies:
  kde: Depends: kdeaddons but it is not going to be installed
       Depends: kdewebdev but it is not going to be installed

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Helge Deller]

On Thursday 23 March 2006 14:54, John David Anglin wrote:
> Generally, I prefer kde but it hasn't been installable on unstable for
> several months:
> 
> The following packages have unmet dependencies:
>   kde: Depends: kdeaddons but it is not going to be installed
>        Depends: kdewebdev but it is not going to be installed

Hi Dave,

both packages (kdeaddons and kdewebdev) are not required packages....
If the others work it should be equally fine (specially kdelibs, kdebase, kdepim).

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[John David Anglin]

> But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it worked fine, so I assume you shouldn't see any problems either...

I tried the default 2.6.16-pa5 from www.parisc-linux.org this afternoon.
I still get a lot of ip_tables messages on the console which unfortunately
aren't captured in any log file.  I've attached the diff between 2.6.15-rc7-pa
and 2.6.16-pa5 dmesg files.  Is the eth0 difference significant?  There's
also a segv in dirmngr that occurs late in both boots.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

--- dmesg	2006-03-25 18:14:38.000000000 -0500
+++ dmesg.0	2006-03-25 18:06:12.000000000 -0500
@@ -1,4 +1,4 @@
-Linux version 2.6.15-rc7-pa1 (bame@palinux) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Mon Jan 2 15:10:49 MST 2006
+Linux version 2.6.16-pa5 (bame@palinux) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Thu Mar 23 20:32:12 MST 2006
 FP[0] enabled: Rev 1 Model 19
 The 32-bit Kernel has started...
 Initialized PDC Console for debugging.
@@ -16,7 +16,7 @@
   HighMem zone: 0 pages, LIFO batch:0
 LCD display at f05d0008,f05d0000 registered
 Built 1 zonelists
-Kernel command line: HOME=/ TERM=linux root=/dev/sdb3 console=tty0 sti=10/4/3/0 sti_font=VGA8x16 panic=180 palo_kernel=3/boot/vmlinux
+Kernel command line: HOME=/ TERM=linux root=/dev/sdb3 console=tty0 sti=10/4/3/0 sti_font=VGA8x16 panic=180 palo_kernel=3/boot/vmlinux-2.6.16-pa5-c3000_defconfig
 PID hash table entries: 4096 (order: 12, 65536 bytes)
 Console: colour dummy device 160x64
 Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
@@ -35,8 +35,8 @@
 6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
 7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
 CPU(s): 1 x PA8700 (PCX-W2) at 875.000000 MHz
-Whole cache flush 1029084 cycles, flushing 4478280 bytes 1046986 cycles
-Setting cache flush threshold to 40 (1 CPUs online)
+Whole cache flush 1257772 cycles, flushing 4495684 bytes 1053408 cycles
+Setting cache flush threshold to 900 (1 CPUs online)
 SBA found Astro 2.1 at 0xfed00000
 LBA version TR4.0 (0x5) found at 0xfed30000
 PCI: Enabled native mode for NS87415 (pif=0x8f)
@@ -48,11 +48,11 @@
 SCSI subsystem initialized
 usbcore: registered new driver usbfs
 usbcore: registered new driver hub
-unwind_init: start = 0x104064d0, end = 0x10434c00, entries = 11891
+unwind_init: start = 0x1040a400, end = 0x10439f10, entries = 12209
 Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
 Initializing Cryptographic API
 io scheduler noop registered
-io scheduler anticipatory registered
+io scheduler anticipatory registered (default)
 io scheduler deadline registered
 io scheduler cfq registered
 SuperIO: Found NS87560 Legacy I/O device at 0000:00:0e.1 (IRQ 19) 
@@ -62,7 +62,7 @@
 SuperIO: Floppy controller at 0x3f0
 SuperIO: ACPI at 0x7e0
 SuperIO: USB regulator enabled
-PDC Stable Storage facility v0.10
+PDC Stable Storage facility v0.22
 Soft power switch enabled, polling @ 0xf0400804.
 STI GSC/PCI core graphics driver Version 0.9a
 STI PCI graphic ROM found at f6000000 (64 kB), fb at f8000000 (32 MB)
@@ -77,21 +77,21 @@
 fb0: stifb 1280x1024-8 frame buffer device, PCI_GRAFFITIX1280, id: 2d08c0a7, mmio: 0xf8100000
 stifb: 'A1262A' (id: 0x35acda30) not supported.
 Generic RTC Driver v1.07
-Serial: 8250/16550 driver $Revision: 1.90 $ 13 ports, IRQ sharing enabled
+Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
 serial8250: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
 serial8250: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
 loop: loaded (max 8 devices)
 Linux Tulip driver version 1.1.13 (December 15, 2004)
 tulip0: no phy info, aborting mtable build
 tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
-eth0: Digital DS21142/DS21143 Tulip rev 65 at f4008000, 00:30:6E:48:AC:EA, IRQ 17.
+eth0: Digital DS21142/DS21143 Tulip rev 65 at 0001e000, 00:30:6E:48:AC:EA, IRQ 17.
 tulip1:  EEPROM default media type Autosense.
 tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
 tulip1:  Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block.
 tulip1:  Index #2 - Media AUI (#2) described by a 21142 Serial PHY (2) block.
 tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
 tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
-eth1: Digital DS21142/DS21143 Tulip rev 33 at f4800000, 00:60:B0:7A:02:FD, IRQ 21.
+eth1: Digital DS21142/DS21143 Tulip rev 33 at 00032000, 00:60:B0:7A:02:FD, IRQ 21.
 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
 NS87415: IDE controller at PCI slot 0000:00:0e.0
@@ -117,8 +117,8 @@
   Type:   Direct-Access                      ANSI SCSI revision: 03
  target1:0:5: tagged command queuing enabled, command queue depth 16.
  target1:0:5: Beginning Domain Validation
- target1:0:5: asynchronous.
- target1:0:5: wide asynchronous.
+ target1:0:5: asynchronous
+ target1:0:5: wide asynchronous
  target1:0:5: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
  target1:0:5: Domain Validation skipping write tests
  target1:0:5: Ending Domain Validation
@@ -126,22 +126,30 @@
   Type:   Direct-Access                      ANSI SCSI revision: 02
  target1:0:6: tagged command queuing enabled, command queue depth 16.
  target1:0:6: Beginning Domain Validation
- target1:0:6: asynchronous.
- target1:0:6: wide asynchronous.
+ target1:0:6: asynchronous
+ target1:0:6: wide asynchronous
  target1:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
  target1:0:6: Domain Validation skipping write tests
  target1:0:6: Ending Domain Validation
 st: Version 20050830, fixed bufsize 32768, s/g segs 256
 SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB)
-SCSI device sda: drive cache: write through
+sda: Write Protect is off
+sda: Mode Sense: d3 00 10 08
+SCSI device sda: drive cache: write through w/ FUA
 SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB)
-SCSI device sda: drive cache: write through
+sda: Write Protect is off
+sda: Mode Sense: d3 00 10 08
+SCSI device sda: drive cache: write through w/ FUA
  sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
 sd 1:0:5:0: Attached scsi disk sda
 SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB)
-SCSI device sdb: drive cache: write through
+sdb: Write Protect is off
+sdb: Mode Sense: a3 00 10 08
+SCSI device sdb: drive cache: write through w/ FUA
 SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB)
-SCSI device sdb: drive cache: write through
+sdb: Write Protect is off
+sdb: Mode Sense: a3 00 10 08
+SCSI device sdb: drive cache: write through w/ FUA
  sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 >
 sd 1:0:6:0: Attached scsi disk sdb
 sd 1:0:5:0: Attached scsi generic sg0 type 0
@@ -172,11 +180,13 @@
 usb usb1: default language 0x0409
 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
 usb usb1: Product: OHCI Host Controller
-usb usb1: Manufacturer: Linux 2.6.15-rc7-pa1 ohci_hcd
+usb usb1: Manufacturer: Linux 2.6.16-pa5 ohci_hcd
 usb usb1: SerialNumber: 0000:00:0e.2
-usb usb1: hotplug
+usb usb1: uevent
+usb usb1: device is self-powered
+usb usb1: configuration #1 chosen from 1 choice
 usb usb1: adding 1-0:1.0 (config #1, interface 0)
-usb 1-0:1.0: hotplug
+usb 1-0:1.0: uevent
 hub 1-0:1.0: usb_probe_interface
 hub 1-0:1.0: usb_probe_interface - got id
 hub 1-0:1.0: USB hub found
@@ -187,7 +197,7 @@
 hub 1-0:1.0: power on to power good time: 0ms
 hub 1-0:1.0: local power source is good
 hub 1-0:1.0: enabling power on all ports
-hub 1-0:1.0: state 5 ports 3 chg 0000 evt 0000
+hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
 drivers/usb/core/inode.c: creating file '001'
 ohci_hcd 0000:00:0e.2: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA PPS CCS
 hub 1-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
@@ -201,11 +211,13 @@
 usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-1: Product: USB Keyboard and Mouse
 usb 1-1: Manufacturer: SILITEK
-usb 1-1: hotplug
+usb 1-1: uevent
+usb 1-1: device is bus-powered
+usb 1-1: configuration #1 chosen from 1 choice
 usb 1-1: adding 1-1:1.0 (config #1, interface 0)
-usb 1-1:1.0: hotplug
+usb 1-1:1.0: uevent
 usb 1-1: adding 1-1:1.1 (config #1, interface 1)
-usb 1-1:1.1: hotplug
+usb 1-1:1.1: uevent
 drivers/usb/core/inode.c: creating file '002'
 ohci_hcd 0000:00:0e.2: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS
 hub 1-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s
@@ -218,11 +230,13 @@
 usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-2: Product: N48
 usb 1-2: Manufacturer: Logitech
-usb 1-2: hotplug
+usb 1-2: uevent
+usb 1-2: device is bus-powered
+usb 1-2: configuration #1 chosen from 1 choice
 usb 1-2: adding 1-2:1.0 (config #1, interface 0)
-usb 1-2:1.0: hotplug
+usb 1-2:1.0: uevent
 drivers/usb/core/inode.c: creating file '003'
-hub 1-0:1.0: state 5 ports 3 chg 0000 evt 0004
+hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0004
 usbcore: registered new driver hiddev
 usbhid 1-1:1.0: usb_probe_interface
 usbhid 1-1:1.0: usb_probe_interface - got id
@@ -239,12 +253,12 @@
 usbcore: registered new driver usbhid
 drivers/usb/input/hid-core.c: v2.6:USB HID core driver
 mice: PS/2 mouse device common for all mice
-md: linear personality registered as nr 1
-md: raid0 personality registered as nr 2
-md: raid1 personality registered as nr 3
+md: linear personality registered for level -1
+md: raid0 personality registered for level 0
+md: raid1 personality registered for level 1
 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
 md: bitmap version 4.39
-Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
+Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
 ALSA device list:
   #0: Analog Devices AD1889 at 0xf400c000 irq 18
 NET: Registered protocol family 2
@@ -263,17 +277,17 @@
 EXT3-fs: mounted filesystem with ordered data mode.
 VFS: Mounted root (ext3 filesystem) readonly.
 Freeing unused kernel memory: 236k freed
-usb 1-0:1.0: hotplug
-usb 1-1: hotplug
-usb 1-1:1.0: hotplug
-usb 1-1:1.1: hotplug
-usb 1-2: hotplug
-usb 1-2:1.0: hotplug
-usb usb1: hotplug
+usb 1-0:1.0: uevent
+usb 1-1: uevent
+usb 1-1:1.0: uevent
+usb 1-1:1.1: uevent
+usb 1-2: uevent
+usb 1-2:1.0: uevent
+usb usb1: uevent
 Adding 265032k swap on /dev/sdb1.  Priority:-1 extents:1 across:265032k
 Adding 263144k swap on /dev/sda1.  Priority:-2 extents:1 across:263144k
 EXT3 FS on sdb3, internal journal
-ip_conntrack version 2.4 (8192 buckets, 65536 max) - 212 bytes per conntrack
+ip_conntrack version 2.4 (8192 buckets, 65536 max) - 172 bytes per conntrack
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on sdb5, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
@@ -289,4 +303,3 @@
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on sda6, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
-ip_tables: (C) 2000-2002 Netfilter core team

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Grant Grundler]

On Sat, Mar 25, 2006 at 08:45:58PM -0500, John David Anglin wrote:
> > But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it worked fine, so I assume you shouldn't see any problems either...
> 
> I tried the default 2.6.16-pa5 from www.parisc-linux.org this afternoon.
> I still get a lot of ip_tables messages on the console which unfortunately
> aren't captured in any log file.

I haven't paid attn to iptables changes but I probably should.
In any case, that will "only" affect things like NAT or firewall.

>   I've attached the diff between 2.6.15-rc7-pa
> and 2.6.16-pa5 dmesg files.  Is the eth0 difference significant?

Yes. One is using MMIO and the other is using IO port space.
c3000defconfig could use MMIO too. I keep forgetting if
the "GSC" Tulips (via card-mode Dino) now reliably can
use MMIO too.

grant

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[Joel Soete]

Grant Grundler wrote:
> On Sat, Mar 25, 2006 at 08:45:58PM -0500, John David Anglin wrote:
> 
[...]
> I keep forgetting if
> the "GSC" Tulips (via card-mode Dino) now reliably can
> use MMIO too.
> 
Btw, I have such additional gsc nic on my d380: which driver should I select?

Tia,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes)

[John David Anglin]

> Did this bug also affect 32bit kernels?  The reason I ask is I
> had to back out using 2.6.16-pa0 on my c3k.  The most obvious
> symptoms were fsck failures on reboot, iptables error messages
> and unreliable behavior of gnome teminal.

The fsck problem turned out to be the same as reported here:
http://lists.debian.org/debian-kernel/2006/02/msg00153.html.
udev was running out of memory and /dev was getting fully populated.

It might be that the udev package got stuck.  I removed and
reinstalled it.  The hack in the debian bug report also seems
to work.

I believe that the iptables problem can be fixed by a config
update but I haven't test it.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)