Re: octeon: oops/panic with CONFIG_SERIO_I8042=y

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/18/2013 01:49 PM, Sergei Shtylyov wrote:
On 07/19/2013 12:42 AM, Manuel Lauss wrote:

On 07/18/2013 11:34 PM, Manuel Lauss wrote:

My goal is to run a standard Debian kernel and its octeon
variant[1] on
the Ubiquity EdgeRouter Lite. The ERLite needs a couple of patches
to boot and work (octeon-ethernet patch, octeon-usb driver) but
these
are already merged 3.11 and I'll file Debian bugs to enable those
settings appropriately.

1: e.g. http://packages.debian.org/sid/linux-image-3.10-1-octeon

However, when trying to boot a standard Debian kernel in the
ERLite I
get a 7s delay followed by an oops for a Data bus error on
i8042_flush()
and ending up with a panic. It looks like the kernel is built with
CONFIG_SERIO_I8042=y.  The Octeon machine Debian owns prints
"i8042: No
controller found" but works nevertheless.  This isn't the case
with the
ERLite; I tried 3.2 & 3.10 and got the same oops which went away as
soon
as I disabled CONFIG_SERIO_I8042.

Are there even any octeon machines with i8042 anyway? Should I
request
for the setting to be disabled irrespective of this bug?

Yes.  There is a rare board called NAC38 that was produced by ASUS
in a 1U chassis.  I don't think it is important to support this, so
the best thing seems to be not to enable SERIO_I8042

I think the real bug here is that IO space does not get properly
initialized on Octeon when there is no PCI? So any drivers trying to
probe IO space will produce some interesting results.

This is not specific to Octeon, I've seen it on Alchemy as well.  A
lot of
drivers, coming from x86, simply assume that x86-Port-IO space is
always available without having to map it first.  I'd say it's a bug in
the various drivers.

    Drivers don't have to map I/O space in any way, it's a complete
nonsense.

isn't that what ioport_map is for?

    ioport_map() permits to use ioread*()/iowrite*(). in*()/out*() don't
need it. It's a job of the arch platform code to map I/O ports into
specific memory range if true I/O space doesn't exist.

Yes, somebody should write a patch to do that.

Probably we should allocate 64K worth of contiguous pages for this if PCI is not enabled.

Who wants to write the patch?  I can test it.

David Daney




[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux