[Top] [All Lists]

Re: octeon: oops/panic with CONFIG_SERIO_I8042=y

To: Manuel Lauss <>
Subject: Re: octeon: oops/panic with CONFIG_SERIO_I8042=y
From: Sergei Shtylyov <>
Date: Fri, 19 Jul 2013 00:49:17 +0400
Cc: Aaro Koskinen <>, David Daney <>, Faidon Liambotis <>, Linux-MIPS <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Organization: Cogent Embedded
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
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.

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


WBR, Sergei

<Prev in Thread] Current Thread [Next in Thread>