Re: octeon: oops/panic with CONFIG_SERIO_I8042=y

[David Daney <ddaney.cavm@gmail.com>]

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