From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Manuel Lauss <manuel.lauss@gmail.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>,
David Daney <ddaney.cavm@gmail.com>,
Faidon Liambotis <paravoid@debian.org>,
Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: octeon: oops/panic with CONFIG_SERIO_I8042=y
Date: Thu, 18 Jul 2013 23:39:46 +0400 [thread overview]
Message-ID: <51E84482.6090706@cogentembedded.com> (raw)
In-Reply-To: <CAOLZvyE-KppwVkb4J8V5k3FHuHKUiQycQiXft5AijPxtSdcL-A@mail.gmail.com>
Hello.
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.
> Manuel
WBR, Sergei
next prev parent reply other threads:[~2013-07-18 19:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 12:25 octeon: oops/panic with CONFIG_SERIO_I8042=y Faidon Liambotis
2013-07-18 16:28 ` David Daney
2013-07-18 18:03 ` Aaro Koskinen
2013-07-18 19:34 ` Manuel Lauss
2013-07-18 19:39 ` Sergei Shtylyov [this message]
2013-07-18 20:42 ` Manuel Lauss
2013-07-18 20:49 ` Sergei Shtylyov
2013-07-18 20:55 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E84482.6090706@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=aaro.koskinen@iki.fi \
--cc=ddaney.cavm@gmail.com \
--cc=linux-mips@linux-mips.org \
--cc=manuel.lauss@gmail.com \
--cc=paravoid@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox