Subject: inb flaky

From: Philip Blundell <[email-masked]>
Date: Fri, 02 Apr 1999 17:37:14 +0100

I've managed to persuade X to run on my CATS now, complete with bt848 
TV-in-a-window.  Cool.

Had a couple of problems along the way though.  It seems that glibc's 
inb and outb are behaving a bit erratically at the moment.  Not sure why; 
it's as if the memory was being mapped cached or something.  For the time 
being I'm using a hacked implementation based on /dev/port but this is 
obviously not the best.  Has anybody else seen this sort of thing on 21285 
hardware?

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Alan Cox <[email-masked]>
Date: Fri, 2 Apr 1999 18:38:07 +0100 (BST)

> obviously not the best.  Has anybody else seen this sort of thing on 21285 

You may be seeing PCI write posting. Try reading a harmless port after
the outb calls
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 02 Apr 1999 20:29:03 +0100

>You may be seeing PCI write posting. Try reading a harmless port after

I think I've found the problem.  It's another effect of this business of 
overloading access information onto the pagetable C and B bits.

The way ioperm works on the ARM is that we open /dev/mem and mmap the 
appropriate range to get access to the ISA ports, then use mprotect to turn 
individual pages on and off to give at least some semblance of individual 
access control.  This was actually inherited from the Alpha port.

Now, the problem is that if you call mprotect(PROT_READ) this 
ends up being translated to a protection value of PAGE_READONLY (via the 
protection_map[] stuff).  And, surprise, PAGE_READONLY is actually
PTE_TYPE_SMALL | PTE_YOUNG | PTE_CACHEABLE.  Oops.

For the time being I guess it can be made to work by just always enabling 
access to all the I/O ports with mmap and never using mprotect.  It's a bit 
nasty though.

p.

---

From: Nicolas Pitre <[email-masked]>
Date: Fri, 2 Apr 1999 19:55:28 -0500 (EST)

> overloading access information onto the pagetable C and B bits.

... and it really sucks on the SA1100 too.

Nicolas Pitre, B. ing.
[email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sat, 03 Apr 1999 11:47:06 +0100

>... and it really sucks on the SA1100 too.

Yeah.  The 110 case is particularly infuriating because the mm code is never 
actually going to *use* the offending bits for an I/O mapping.  Oh well.

I thought about this a little more in the shower this morning and I think I 
now have a plan for fixing this.  I'll try to implement it today.  The basic 
idea is the same one of Russell's that you mentioned; I've failed to think of 
anything better.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 3 Apr 1999 17:36:50 +0100 (BST)

> idea is the same one of Russell's that you mentioned; I've failed to think of 

Ok, I've seen enough to warrant it appearing in 2.2.  I've got my own plan on
how to do this...
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sat, 03 Apr 1999 18:07:58 +0100

>Ok, I've seen enough to warrant it appearing in 2.2.  I've got my own plan on

Are you volunteering to write it?

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 3 Apr 1999 22:33:01 +0100 (BST)

> Are you volunteering to write it?

Already done, with SA-110 rev. K bug fix as well.  All that remains is
thorough testing.
   _____