On Sat, Mar 29, 2014 at 02:16:38PM +0100, Donovan Watteau wrote: > On Sun, 23 Mar 2014, Mark Kettenis wrote: > > > Date: Sun, 23 Mar 2014 17:53:47 +0100 (CET) > > > From: Donovan Watteau <tso...@gmail.com> > > > > > > ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: apic 2 int 23 > > > panic: kernel diagnostic assertion "(reg & 0x3) == 0" failed: file > > > "../../../ > > > arch/amd64/pci/pci_machdep.c", line 272 > > > Stopped at Debugger+0x5: leave > > > Debugger() at Debugger+0x5 > > > panic() at panic+0xee > > > __assert() at __assert+0x21 > > > pci_conf_read() at pci_conf_read+0xdd
Ignoring the unaligned memory access for a moment, should ehci_pci even be using pci_conf_*(9) here? The registers it's accessing aren't technically part of the devices PCI configuration space. .. > > > ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b > > > ehci_pci_attach() at ehci_pci_attach+0x22a > > > config_attach() at config_attach+0x1bc > > > pci_probe_device() at pci_probe_device+0x447 > > > pci_enumerate_bus() at pci_enumerate_bus+0xe9 > > > config_attach() at config_attach+0x1bc > > > end trace frame: 0xffffffff81edce80, count: 0 > > > RUN AT LEASE 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS > > > PANIC! > > > DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! > > > ddb> trace > > > Debugger() at Debugger+0x5 > > > panic() at panic+0xee > > > __assert() at __assert+0x21 > > > pci_conf_read() at pci_conf_read+0xdd > > > ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b > > > ehci_pci_attach() at ehci_pci_attach+0x22a > > > config_attach() at config_attach+0x1bc > > > pci_probe_device() at pci_probe_device+0x447 > > > pci_enumerate_bus() at pci_enumerate_bus+0xe9 > > > config_attach() at config_attach+0x1bc > > > mainbus_attach() at mainbus_attach+0x163 > > > config_attach() at config_attach+0x1bc > > > cpu_configure() at cpu_configure+0x17 > > > main() at main+0x41c > > > end trace frame: 0x0, count: -14 > > > ddb> ps > > > PID PPID PGRP UID S FLAGS WAIT COMMAND > > > * 0 -1 0 0 7 0x200 swapper > > > ddb> > > > > Can you send the output of pcidump -vxx from that machine? > > > > Here you go: > > ... > 0:3:3: SiS 7002 USB > 0x0000: Vendor ID: 1039 Product ID: 7002 > 0x0004: Command: 0006 Status: 0290 > 0x0008: Class: 0c Subclass: 03 Interface: 20 Revision: 00 > 0x000c: BIST: 00 Header Type: 00 Latency Timer: 20 Cache Line Size: 08 > 0x0010: BAR mem 32bit addr: 0xef002000/0x00001000 > 0x0014: BAR empty (00000000) > 0x0018: BAR empty (00000000) > 0x001c: BAR empty (00000000) > 0x0020: BAR empty (00000000) > 0x0024: BAR empty (00000000) > 0x0028: Cardbus CIS: 00000000 > 0x002c: Subsystem Vendor ID: 17aa Product ID: 100a > 0x0030: Expansion ROM Base Address: 00000000 > 0x0038: 00000000 > 0x003c: Interrupt Pin: 04 Line: 03 Min Gnt: 00 Max Lat: 50 > 0x0050: Capability 0x01: Power Management > 0x0000: 70021039 02900006 0c032000 00002008 > 0x0010: ef002000 00000000 00000000 00000000 > 0x0020: 00000000 00000000 00000000 100a17aa > 0x0030: 00000000 00000050 00000000 50000403 > 0x0040: 08000000 00000000 00000000 00000000 > 0x0050: c9c20001 00000003 2100000a 00000000 > 0x0060: 01ff2020 00000000 00000000 00000000 > 0x0070: 00000001 c0000000 3fff0000 00000000 > 0x0080: 00000000 00000000 00000000 00000000 > 0x0090: 00000000 00000000 00000000 00000000 > 0x00a0: 00000000 00000000 00000000 00000000 > 0x00b0: 00000000 00000000 00000000 00000000 > 0x00c0: 00000000 00000000 00000000 00000000 > 0x00d0: 00000000 00000000 00000000 00000000 > 0x00e0: 00000000 00000000 00000000 00000000 > 0x00f0: 00000000 00000000 00000000 00000000 ... Of course, using bus_space(9) would have hidden this panic on i386/amd64. :-) -Bryan.
