Subject: octeon: oops/panic with CONFIG_SERIO_I8042=y

From: Faidon Liambotis <[email-masked]>
Date: Thu, 18 Jul 2013 15:25:56 +0300

Hi,

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?

The oops is as follows:
[    1.702762] ehci-pci: EHCI PCI platform driver
[    1.707913] usbcore: registered new interface driver usb-storage
[    8.591312] Data bus error, epc == ffffffff81446838, ra == ffffffff814467f0
[    8.598102] Oops[#1]:
[    8.600360] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0 #5
[    8.606253] task: a80000041f869540 ti: a80000041f86c000 task.ti: a80000041f86c000
[    8.613706] $ 0   : 0000000000000000 0000000000000000 0000000000000000 0000000000010000
[    8.621684] $ 4   : 0000000000000000 a80000041f1bbb40 000000000000006f ffffffff816ffe60
[    8.629662] $ 8   : 0000000000000000 000000000000005b 726564206e657720 696e746572666163
[    8.637640] $12   : 0000000000000000 ffffffff8136b0dc ffffffff81790000 0000000000000000
[    8.645619] $16   : 80011a0400000064 80011a0400000000 0000000000000010 ffffffff817a0000
[    8.653597] $20   : ffffffff817a0000 0000000000000001 ffffffff81770e20 ffffffff817a0000
[    8.661575] $24   : 0000000000000004 ffffffff81790000                                  
[    8.669553] $28   : a80000041f86c000 a80000041f86fd70 0000000000000000 ffffffff814467f0
[    8.677532] Hi    : 0000000000acd49d
[    8.681088] Lo    : 0e5604189441f8e5
[    8.684661] epc   : ffffffff81446838 i8042_flush+0x80/0x118
[    8.690194]     Not tainted
[    8.692975] ra    : ffffffff814467f0 i8042_flush+0x38/0x118
[    8.698518] Status: 10008ce2	KX SX UX KERNEL EXL 
[    8.703201] Cause : 4080801c
[    8.706064] PrId  : 000d0601 (Cavium Octeon+)
[    8.710398] Modules linked in:
[    8.713439] Process swapper/0 (pid: 1, threadinfo=a80000041f86c000, task=a80000041f869540, tls=0000000000000000)
[    8.723580] Stack : ffffffff81700000 ffffffff81751158 0000000000000000 ffffffff8175f2f8
	  ffffffff817361d8 ffffffff8175f288 ffffffff81770e20 ffffffff816c0000
	  000000000000008c ffffffff817511ac 0000000000000000 ffffffff81780000
	  ffffffff81751158 ffffffff811004e0 ffffffff817361d8 0000000000000030
	  ffffffff81780000 0000000000000007 ffffffff8175f2f8 ffffffff81736b50
	  ffffffff81595080 0000000000000000 ffffffff81780000 0000000000000000
	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
	  0000000000000000 ffffffff8159509c ffffffff81595080 0000000000000000
	  0000000000000000 ffffffff8111a124 0000000000000000 0000000000000000
	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
	  ...
[    8.788447] Call Trace:
[    8.790882] [<ffffffff81446838>] i8042_flush+0x80/0x118
[    8.796092] [<ffffffff817511ac>] i8042_init+0x54/0xf0
[    8.801118] [<ffffffff811004e0>] do_one_initcall+0xe0/0x130
[    8.806658] 
[    8.808132] 
Code: 14800017  27de0001  92020000 <305600ff> cac00003  24040032  17d2fff4  00200825  6684d338 
[    8.820195] ---[ end trace 76cca175541407ab ]---
[    8.824650] note: swapper/0[1] exited with preempt_count 1
[    8.830188] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    8.830188] 

Regards,
Faidon

---

From: David Daney <[email-masked]>
Date: Thu, 18 Jul 2013 09:28:54 -0700

> 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

David Daney

> [    8.661575] $24   : 0000000000000004 ffffffff81790000 [    8.669553]
> $28   : a80000041f86c000 a80000041f86fd70 0000000000000000 ffffffff814467f0
> [    8.698518] Status: 10008ce2    KX SX UX KERNEL EXL [    8.703201]
> Cause : 4080801c
> [    8.713439] Process swapper/0 (pid: 1, threadinfo=a80000041f86c000,
> task=a80000041f869540, tls=0000000000000000)
> [    8.806658] [    8.808132] Code: 14800017  27de0001  92020000
> <305600ff> cac00003  24040032  17d2fff4  00200825  6684d338 [
> 8.820195] ---[ end trace 76cca175541407ab ]---

---

From: Aaro Koskinen <[email-masked]>
Date: Thu, 18 Jul 2013 21:03:39 +0300

Hi,

On Thu, Jul 18, 2013 at 09:28:54AM -0700, David Daney wrote:
> 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.

A.

---

From: Manuel Lauss <[email-masked]>
Date: Thu, 18 Jul 2013 21:34:28 +0200

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

Manuel

---

From: Sergei Shtylyov <[email-masked]>
Date: Thu, 18 Jul 2013 23:39:46 +0400

Hello.

> always available without having to map it first.  I'd say it's a bug in

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

> Manuel

WBR, Sergei

---

From: Manuel Lauss <[email-masked]>
Date: Thu, 18 Jul 2013 22:42:28 +0200

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

Manuel

---

From: Sergei Shtylyov <[email-masked]>
Date: Fri, 19 Jul 2013 00:49:17 +0400

> 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

---

From: David Daney <[email-masked]>
Date: Thu, 18 Jul 2013 13:55:58 -0700

On 07/18/2013 01:49 PM, Sergei Shtylyov wrote:
>     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