linuxsh-dev

HP6xx 2.6.20 kernel producing unaligned access errors

[Kristoffer E. <kri...@ho...>]

Greetings,

I tried to get pata support working properly and it now detects the CF slot 
and the sandisk card inside it (with correct size). Upon bootup (from root 
device) it produces these errors:

Freeing unused kernel memory: 68k freed
Fixing up unaligned userspace access in "hotplug" pid=181 pc=0x000141ea 
ins=0x5436
Fixing up unaligned userspace access in "hotplug" pid=181 pc=0x000141ee 
ins=0x0203
Sending SIGBUS to "hotplug" due to unaligned access (PC 141f1 PR 141f2)
Fixing up unaligned userspace access in "hotplug" pid=182 pc=0x000141ea 
ins=0x5436
Fixing up unaligned userspace access in "hotplug" pid=182 pc=0x000141ee 
ins=0x0203
Sending SIGBUS to "hotplug" due to unaligned access (PC 141f1 PR 141f2)

I've attached the pata patch and please note that the only driver left to 
implement is the hp6xx keyboard (if that has anything to do with it for 
whatever reason).

Best wishes
Kristoffer Ericson

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

PATA Patch for Hp6xx

[Kristoffer E. <kri...@ho...>]

(forgot to attach patch)

#include <asm/irq.h>
#include <asm/hp6xx.h>
#include <asm/cpu/dac.h>
+#include <linux/platform_device.h>

#define	SCPCR	0xa4000116
#define SCPDR	0xa4000136

+static struct resource cf_ide_resources[] = {
+              [0] = {
+	              .start = 0x1f0,
+		      .end   = 0x1f0 + 8,
+		      .flags = IORESOURCE_IO,
+		      },
+	      [1] = {
+	              .start = 0x1f0 + 0x206,               <------------ Error?
+		      .end   = 0x1f0 +8 + 0x206 + 8,
+		      .flags = IORESOURCE_IO,
+		    },
+              [2] = {
+	              .start = 93,
+		      .flags = IORESOURCE_IRQ,
+		    },
+};
+
+static struct platform_device cf_ide_device = {
+              .name         =  "pata_platform",
+	      .id           =  -1,
+	      .num_resources = ARRAY_SIZE(cf_ide_resources),
+	      .resource      = cf_ide_resources,
+};
+
+static struct platform_device *hp6xx_devices[] __initdata = {
+
+       &cf_ide_device,
+};
+
+static int __init hp6xx_devices_setup(void)
+{
+ return platform_add_devices(hp6xx_devices,ARRAY_SIZE(hp6xx_devices));
+}
+
static void __init hp6xx_setup(char **cmdline_p)
{
	u8 v8;
	u16 v;

+        device_initcall(hp6xx_devices_setup);
+
	v = inw(HD64461_STBCR);
	v |= HD64461_STBCR_SURTST | HD64461_STBCR_SIRST |
	    HD64461_STBCR_STM1ST | HD64461_STBCR_STM0ST |

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

Re: PATA Patch for Hp6xx

[Manuel L. <ma...@ro...>]

On Thu, Mar 01, 2007 at 11:43:28PM +0000, Kristoffer Ericson wrote:
> +	              .start = 0x1f0 + 0x206,               <------------ Error?
> +		      .end   = 0x1f0 +8 + 0x206 + 8,
> +		      .flags = IORESOURCE_IO,

3f6 is correct. .end should be 3f7. (have alook at
arch/sh/cchips/hd6446x/hd64461/io.c::PORT2ADDR()).

Maybe you could even use the "real" MMIO addresses of
the hd64461 pcmcia0 region (0xb50001f0), and one day get rid of
that ugly io.c file altogether...

-- 
 ml.

Re: PATA Patch for Hp6xx

[Paul M. <le...@li...>]

On Fri, Mar 02, 2007 at 07:06:09AM +0100, Manuel Lauss wrote:
> On Thu, Mar 01, 2007 at 11:43:28PM +0000, Kristoffer Ericson wrote:
> > +	              .start = 0x1f0 + 0x206,               <------------ Error?
> > +		      .end   = 0x1f0 +8 + 0x206 + 8,
> > +		      .flags = IORESOURCE_IO,
> 
> 3f6 is correct. .end should be 3f7. (have alook at
> arch/sh/cchips/hd6446x/hd64461/io.c::PORT2ADDR()).
> 
> Maybe you could even use the "real" MMIO addresses of
> the hd64461 pcmcia0 region (0xb50001f0), and one day get rid of
> that ugly io.c file altogether...
> 
Indeed, and in this case, there's really no reason _not_ to use the MMIO
address. The reason some folks were using the PIO addresses before were
as a lame way to take care of port shifting, and this is really the wrong
way to go about it. If there's a real inability to do an access of that
size, then it's something the driver has to deal with, we shouldn't be
papering over it in the machvec.

I would say rip out the HD64461 entries from the machvec entirely and see
what falls out. I imagine PCMCIA will be a problem, but this needs an
overhaul for the hardirq changes anyways, and then we're likely left with
something much smaller that we can push in as an MFD driver, and kill off
the rest of the cchip mess.

The io.c's have always been utter crap, the sooner we can kill off the
outstanding ones, the better.

Re: PATA Patch for Hp6xx

[Kristoffer E. <kri...@ho...>]

Big thanks, I'll sort it out later today.


>From: Paul Mundt <le...@li...>
>To: Manuel Lauss <ma...@ro...>
>CC: Kristoffer Ericson 
><kri...@ho...>,lin...@li...
>Subject: Re: PATA Patch for Hp6xx
>Date: Fri, 2 Mar 2007 15:30:14 +0900
>
>On Fri, Mar 02, 2007 at 07:06:09AM +0100, Manuel Lauss wrote:
> > On Thu, Mar 01, 2007 at 11:43:28PM +0000, Kristoffer Ericson wrote:
> > > +	              .start = 0x1f0 + 0x206,               <------------ 
>Error?
> > > +		      .end   = 0x1f0 +8 + 0x206 + 8,
> > > +		      .flags = IORESOURCE_IO,
> >
> > 3f6 is correct. .end should be 3f7. (have alook at
> > arch/sh/cchips/hd6446x/hd64461/io.c::PORT2ADDR()).
> >
> > Maybe you could even use the "real" MMIO addresses of
> > the hd64461 pcmcia0 region (0xb50001f0), and one day get rid of
> > that ugly io.c file altogether...
> >
>Indeed, and in this case, there's really no reason _not_ to use the MMIO
>address. The reason some folks were using the PIO addresses before were
>as a lame way to take care of port shifting, and this is really the wrong
>way to go about it. If there's a real inability to do an access of that
>size, then it's something the driver has to deal with, we shouldn't be
>papering over it in the machvec.
>
>I would say rip out the HD64461 entries from the machvec entirely and see
>what falls out. I imagine PCMCIA will be a problem, but this needs an
>overhaul for the hardirq changes anyways, and then we're likely left with
>something much smaller that we can push in as an MFD driver, and kill off
>the rest of the cchip mess.
>
>The io.c's have always been utter crap, the sooner we can kill off the
>outstanding ones, the better.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/