Bug 20248
| Summary: | DEFPA FDDI on alpha panics system | ||
|---|---|---|---|
| Product: | Base System | Reporter: | wilko <wilko> |
| Component: | alpha | Assignee: | freebsd-alpha (Nobody) <alpha> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
It appears that the probe on alpha is quite incomplete, judging from the messages the kernel displays on boot: Alpha probe messages: fpa0: <Digital DEFPA PCI FDDI Controller> port 0x9000-0x907f mem 0x80950000-0x80 95ffff,0x80975000-0x8097507f irq 4 at device 11.0 on pci0 fpa0: interrupting at CIA irq 4 fpa0: driver is using old-style compatability shims Intel probe messages: fpa0: <Digital DEFPA PCI FDDI Controller> port 0xe400-0xe47f mem 0xfbf90000-0xfbf9ffff,0xfbfaf000-0xfbfaf07f irq 9 at device 9.0 on pci0 fpa0: DEC DEFPA PCI FDDI SAS Controller fpa0: FDDI address 00:00:f8:43:c4:53, FW=3.10, HW=1, SMT V7.2 fpa0: FDDI Port = S (PMD = ANSI Multi-Mode) fpa0: driver is using old-style compatability shims The missing messages are produced by pdq_print_fddi_chars() which is only called by pdq_process_command_responses(). It appears the kernel cannot send commands to the card correctly (and/or receive the commands). This is in line with the fact that ifconfig can UP the interface but never a RING UP condition is detected. -- Wilko Bulte wilko@freebsd.org Arnhem, the Netherlands State Changed From-To: open->closed fpa driver is fixed in -current for some time now. Verified with DEFPA in a Miata MX5 talking to a PPro running FreeBSD as well. |
presence of 'device fpa' in the kernel produces a panic on boot as follows: isp0: interrupting at CIA irq 3 fpa0: <Digital DEFPA PCI FDDI Controller> port 0x8100-0x817f mem 0x80800000-0x8080ffff,0x80821000-0x8082107f irq 16 at device 9.0 on pci1 fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x80821014 a1 = 0x1 a2 = 0x0 pc = 0xfffffc0000369158 ra = 0xfffffc0000368e98 curproc = 0xfffffc000057e988 pid = 0, comm = swapper ddbprinttrap from 0xfffffc0000369158 ddbprinttrap(0x80821014, 0x1, 0x0, 0x2) panic: trap panic Stopped at Debugger+0x2c: ldq ra,0(sp) <0xfffffc00005e5900> <ra=0xfffffc00004c3ca0,sp=0xfffffc00005e5900> db> t Debugger() at Debugger+0x2c panic() at panic+0x100 trap() at trap+0x610 XentMM() at XentMM+0x20 pdq_initialize() at pdq_initialize+0x278 (null)() at 0x6 db> and fffffc00003688e0 T pdq_interrupt fffffc0000368c20 T pdq_initialize fffffc00003691c0 T pdq_ifinit fffffc0000369300 T pdq_ifwatchdog fffffc0000369380 T pdq_ifstart fffffc0000369520 T pdq_os_receive_pdu fffffc0000369620 T pdq_os_restart_transmitter It seems something in pdq_initialize might be doing something wrong. At least, it does on alpha. I tested with one DEFPA in a current i386 FreeBSD box and the other one in the Miata running T64 4.0G. That works just fine. Fix: Thanks to Andrew Gallatin for: This solves the panic condition. It does not, however result in a working DEFPA/FDDI link. Note that de fpa driver in -current (I think this is the same as in 4.1) on i386 works just fine.--SHjyiHTBl4yfT0dazyU3uybrrTJSHTlS8vmlwaEp34iLPZTF Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" Index: pci/pci_compat.c =================================================================== RCS file: /home/ncvs/src/sys/pci/pci_compat.c,v retrieving revision 1.35 diff -u -r1.35 pci_compat.c --- pci/pci_compat.c 2000/02/28 08:12:24 1.35 +++ pci/pci_compat.c 2000/07/25 15:03:00 @@ -96,7 +96,7 @@ rid = reg; res = bus_alloc_resource(cfg->dev, SYS_RES_MEMORY, &rid, - 0, ~0, 1, RF_ACTIVE); + 0, ~0, 1, RF_ACTIVE|PCI_RF_DENSE); if (res) { *pa = rman_get_start(res); *va = (vm_offset_t) rman_get_virtual(res); How-To-Repeat: See above