headers
Matt Reimer | 1 Dec 2005 01:23
Favicon

Re: Execute from CF causes segmentation faults

On Nov 30, 2005, at 2:37 PM, Russell King - ARM Linux wrote:
>
> This also reminds me about the MTD flush_dcache_page() patch (below)
> which I produced and never heard back whether it fixed anything...
> Would be nice to actually fix some of these issues... but someone
> needs to reproduce the problem without this patch and then check that
> it does fix it.

FWIW, I've been running this patch for some time without a problem,  
but I haven't provoked the problem without the patch to know whether  
it's really fixing anything.

Matt

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 0 comments |
headers
Charles Manning | 1 Dec 2005 01:44
Picon
Picon

RE: Execute from CF causes segmentation faults


> -----Original Message-----
> From: linux-arm-kernel-bounces <at> lists.arm.linux.org.uk 
> [mailto:linux-arm-kernel-bounces <at> lists.arm.linux.org.uk] On 
> Behalf Of Russell King - ARM Linux
> Sent: Thursday, 1 December 2005 11:18 a.m.
> To: Nicolas Pitre
> Cc: ''linux-arm-kernel <at> lists.arm.linux.org.uk' '; 'Ian Campbell '
> Subject: Re: Execute from CF causes segmentation faults
> 
> On Wed, Nov 30, 2005 at 04:46:15PM -0500, Nicolas Pitre wrote:
> > On Thu, 1 Dec 2005, James Steward wrote:
> > 
> > > The originator of the discussion who I believe was Lothar 
> Wassmann, 
> > > proposed a patch to fix this problem it seems.  Is the kernel 
> > > command line option a real fix or a bandaid I wonder?
> > 
> > Definitively a bandaid as it also affect cache performance.
> 
> This really does need fixing... (don't look at me)

Something that confuses me lightly is why this problem should exist at
all.

It seems that the problem is caused by stale data in the cache. 
Surely cache data should never be stale (ie. Anything in the cache
should be current).

It also seems odd to me that this requires fixes at the block driver
(Continue reading)

Permalink | Reply | 1 comment |
headers
nicola perrino | 1 Dec 2005 10:54
Picon

Re: PXA27x host port 2 non functional

Hi Bernd,

you have reason ..
This is only my custom solution. 
I hope this solution can help someone.
It should be:

      .....................
      if (machine_is_mainstone())  {
               /* setup Port1 GPIO pin. */
               pxa_gpio_mode( 88 | GPIO_ALT_FN_1_IN);  /* USBHPWR1 */
               pxa_gpio_mode( 89 | GPIO_ALT_FN_2_OUT); /* USBHPEN1 */

               /* Set the Power Control Polarity Low and Power Sense
                  Polarity Low to active low. Supply power to USB ports.
*/
               UHCHR = (UHCHR | UHCHR_PCPL | UHCHR_PSPL) &
                       ~(UHCHR_SSEP1 | UHCHR_SSEP2 | UHCHR_SSEP3 |
UHCHR_SSE);
       }

      if (machine_is_myboard()) {
               /* setup Port1 GPIO pin. */
               pxa_gpio_mode( 88 | GPIO_ALT_FN_1_IN);  /* USBHPWR1 */
               pxa_gpio_mode( 89 | GPIO_ALT_FN_2_OUT); /* USBHPEN1 */

               /* setup Port2 GPIO pin. */
               pxa_gpio_mode( 119 |GPIO_ALT_FN_1_IN);   /* USBHPWR2 */
               pxa_gpio_mode( 120 | GPIO_ALT_FN_2_OUT); /* USBHPEN2 */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Konstantin Kletschke | 1 Dec 2005 10:46
Picon

Re: i.MX I2C iu linux-2.6.14 ?


Well, at our company we have rather good i2c implementation which I
could put onto a website or send to individual people. 

It works and compiles for 2.6.13. 

I want to release an all in one BSP including our i2c stuff since ages
but I am still not able to cope with to show stoppers, so I could cut
out the i2c stuff only. 

btw. this i2c stuff does not compile with .14 due to changes in one or
some structures, I will show off with this here later ;)

Regards, Konsti

--

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 1 comment |
headers
Romain Goyet | 1 Dec 2005 11:09
Picon

Changes in arch/arm/mm between 2.6.13 and 2.6.15

Hello everybody,
  I'm porting Linux to the Palm Tungsten E (featuring an ARM925T
processor), and it happened that Linux stopped working when I upgraded
from 2.6.13 to 2.6.15.
  My biggest problem is that this board has _no_ UART nor JTAG, so
it's _very_ difficult to debug. I managed to find out that the kernel
crashes in paging_init, but I couldn't find out why.
  Could you give me any suggestions ? In particular, I would like to
know what changed in arch/arm/mm between 2.6.13 and 2.6.15, since
2.6.13 was working like a charm.

Kind regards,

Romain Goyet

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 10 comments |
headers
Russell King - ARM Linux | 1 Dec 2005 11:58
Picon

Re: [RFC] pfn_to_kaddr

On Wed, Nov 30, 2005 at 10:05:12AM +0900, Hiroki Kaminaga wrote:
> Hi,
> 
> I'd like to use pfn_to_kaddr in arm linux kernel.
> 
> On other arch, it is defined in include/asm/page.h, like below:
> #define pfn_to_kaddr(pfn)    __va((pfn) << PAGE_SHIFT)
> 
> However, there is no def in arm.
> Is it possible to add def of pfn_to_kaddr in, say include/asm/memory.h?

Yes, please send a patch to the patch system.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Dec 2005 12:02
Picon

Re: Execute from CF causes segmentation faults

On Thu, Dec 01, 2005 at 01:44:59PM +1300, Charles Manning wrote:
> Something that confuses me lightly is why this problem should exist at
> all.
> 
> It seems that the problem is caused by stale data in the cache. 
> Surely cache data should never be stale (ie. Anything in the cache
> should be current).

No.  I think what is happening is:
* the page we submit to the block layer has some cache lines already
  associated with the kernel mapping.
* the IDE driver uses PIO to read from CF and hits these cache lines
  making them dirty.
* the page is then mapped into userspace via a page fault.
* userspace reads the page.  Because some of the data is sitting in
  the cache corresponding with the kernel mapping of the page,
  userspace doesn't see the up to date data until later.

> It also seems odd to me that this requires fixes at the block driver
> level. I'd have thought this would get resolved at the page cache
> level, or fs level at absolute lowest.

If you do it there, you hurt DMA performance.  The DMA model ensures
cache coherency.  The IDE PIO IO model does not.

Basically, the problem stems from IDE PIO IO not providing the same
cache guarantees as other block device drivers do.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric BENARD / Free | 1 Dec 2005 12:30
Picon
Favicon

PXA255 resume : MCI

Hi,

I'm trying to get resume working on a PXA255 running kernel 2.6.14 and I found 
that the MCI driver is blocking the resume process.

here is some log :
# echo mem > /sys/power/state
Stopping tasks: ==========|

now I press the button which wakes up the CPU :

MMC: starting cmd 07 arg 5d1d0000 flags 00000009
pxamci_request
pxamci_stop_clock
pxamci_start_cmd

pxamci_suspend & pxamci_resume  are not called at suspend & resume, is this an 
expected behaviour ?

suspend/resume works fine without the pxamci driver.

Any idea of what could be wrong ?

Thanks
Eric

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russell King - ARM Linux | 1 Dec 2005 12:42
Picon

Re: PXA255 resume : MCI

On Thu, Dec 01, 2005 at 12:30:55PM +0100, Eric BENARD / Free wrote:
> I'm trying to get resume working on a PXA255 running kernel 2.6.14 and
> I found that the MCI driver is blocking the resume process.

This should have been fixed 4 weeks ago.  Patch 3120/1

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 1 comment |
headers
Michael Burian | 1 Dec 2005 12:58
Picon

Re: Changes in arch/arm/mm between 2.6.13 and 2.6.15

Romain Goyet wrote:
> Hello everybody,
>   I'm porting Linux to the Palm Tungsten E (featuring an ARM925T
> processor), and it happened that Linux stopped working when I upgraded
> from 2.6.13 to 2.6.15.
>   My biggest problem is that this board has _no_ UART nor JTAG, so
> it's _very_ difficult to debug. I managed to find out that the kernel
> crashes in paging_init, but I couldn't find out why.

Similar problem here on EP93xx, I've seen this behavoir already when
going from v2.6.13 -> v2.6.14.

Could you test with v2.6.14?

In order to be able to boot again I had to remove several drivers.
Right now I'm testing what drivers could have caused this by enabling
them one by one.

Here's what I've observed:

All drivers work together in our last 2.6.13 version

After merging our last 2.6.13 version with 2.6.14 and trying to compile
a defconfig (which had to be modified too) the kernel no longer boots.

After removing several drivers the kernel boots again.

Compiling in the sound driver crashes (unconditionally)

Some drivers work when compiled alone, but crash on bootup when used
(Continue reading)

Permalink | Reply | 9 comments |

Gmane