kern/87363: viapm(4) breaks PCI-ISA bridge --> no sc(4) --> console freezes

[Oliver Fromme]

>Number:         87363
>Category:       kern
>Synopsis:       viapm(4) breaks PCI-ISA bridge --> no sc(4) --> console freezes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 13 09:40:15 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Oliver Fromme
>Release:        FreeBSD 6.0-RC1 i386
>Organization:
secnetix GmbH & Co. KG, Munich, Germany
>Environment:
System: FreeBSD epia.fromme.com 6.0-RC1 FreeBSD 6.0-RC1 #0: Wed Oct 12 17:21:20 CEST 2005 olli at epia.fromme.com:/usr/src/sys/i386/compile/EPIA i386

This is a VIA EPIA PD-10000 mainboard with VIA VT8233 / VT8235
south bridge.  I believe that all systems with those south
bridges are affected by the problem.

>Description:

When you put "device viapm" in your kernel configuration,
the VGA console (syscons) freezes upon boot as soon as the
kernel detects the viapropm0 device.  Freeze means:  The
output from the boot process stops, no keyboard input is
possible.  Meanwhile, the system boots up normally, login
via ssh is possible.  Only the console I/O is dead.

The following is a diff of dmesg between a kernel without
viapm and with viapm.  From the diff output it is clear
that the PCI-ISA bridge is not detected anymore.  My guess
is that the viapm(4) driver somehow "swallows" the device,
so the isab driver doesn't get a chance anymore to attach
to it.

Here's the diff:

--- /var/run/dmesg.previous	Wed Oct 12 16:39:06 2005
+++ /var/run/dmesg.boot	Thu Oct 13 08:06:05 2005
@@ -60,8 +60,12 @@
 usb3: USB revision 2.0
 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
 uhub3: 6 ports with 6 removable, self powered
-isab0: <PCI-ISA bridge> at device 17.0 on pci0
-isa0: <ISA bus> on isab0
+viapropm0: SMBus I/O base at 0x500
+viapropm0: SMBus I/O base at 0x500
+viapropm0: <VIA VT8233/8235 Power Management Unit> port 0x500-0x50f at device 17.0 on pci0
+viapropm0: SMBus revision code 0x0
+smbus0: <System Management Bus> on viapropm0
+smb0: <SMBus generic I/O> on smbus0
 atapci0: <VIA 8235 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 17.1 on pci0
 ata0: <ATA channel 0> on atapci0
 ata1: <ATA channel 1> on atapci0
@@ -94,11 +98,6 @@
 sio2: type 16550A
 sio3: <16550A-compatible COM port> port 0x2e8-0x2ef irq 10 on acpi0
 sio3: type 16550A
-pmtimer0 on isa0
-orm0: <ISA Option ROM> at iomem 0xc0000-0xcdfff on isa0
-sc0: <System console> at flags 0x100 on isa0
-sc0: VGA <16 virtual consoles, flags=0x300>
-vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
 Timecounter "TSC" frequency 1002280476 Hz quality 800
 Timecounters tick every 1.000 msec
 ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging disabled

Complete output from "dmesg", "pciconf -lv" and "sysctl dev hw"
can be found here:

http://www.secnetix.de/~olli/dmesg/epia/

>How-To-Repeat:

Enable "device viapm" on a system with VIA VT8233 / VT8235,
reboot, and watch the VGA console freezing.

>Fix:

Unfortunately, I'm not a kernel hacker.  I can only guess
that the viapm(4) driver is occupying the device so the
isab driver can't attach to it anymore.  It should be
possible to resolve this so both drivers can attach.
Sadly, I'm not an expert, so I have no idea how to do that.

If anyone needs any further information, I'm happy to
provide anything I can.

>Release-Note:
>Audit-Trail:
>Unformatted: