Subject: panic in tlp(4) when atalkd starts on a "down" interface
To: NetBSD/Alpha Discussion List <port-alpha@NetBSD.org>
From: Greg A. Woods <woods@planix.com>
List: port-alpha
Date: 10/19/2006 19:53:25
--pgp-sign-Multipart_Thu_Oct_19_19:53:15_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
I've encountered the following panic in tlp(4) when atalkd is started
(by accident) on an unconfigured interface
Actually I'm not 100% sure what the exact state of the interface was,
but I don't believe it had been touched by any ifconfig command between
boot (I've since created an /etc/ifconfig.tlp0 but I don't believe it
was there at the time I was encountering the panic). At the moment I'm
unable to reboot this machine again to test, and the only other Alpha I
have which could be rebooted at the moment doesn't have a tlp(4)
interface that could be used to test on. I don't think there was any
link status at the time either, though if necessary I'll have to
schedule downtime before I can reproduce the problem and see for sure
what the exact interface status is at the time it crashes.
Here's how the interface looks in at boot time:
tlp0 at pci0 dev 5 function 0: DECchip 21140A Ethernet, pass 2.0
tlp0: interrupting at kn300 irq 52
tlp0: DEC DE500-AA, Ethernet address 00:00:f8:06:f4:fb
ukphy0 at tlp0 phy 5: Generic IEEE 802.3u media interface
ukphy0: NS DP83840 10/100 media interface (OUI 0x1000e8, model 0x0000), rev=
. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
(I should have the right PHY driver for this card in my next kernel, but
this interface is only intended for my test network, which is why
starting atalkd on it was a mistake in the first place.)
---------- from /etc/netatalk/atalkd.conf:
tlp0 -phase 2 -net 1-65534 -addr 65280.250
---------- end of /etc/netatalk/atalkd.conf
---------- from the console log:
Starting atalkd.
CPU 2: fatal kernel trap:
CPU 2 trap entry =3D 0x2 (memory management fault)
CPU 2 a0 =3D 0x10
CPU 2 a1 =3D 0x1
CPU 2 a2 =3D 0x1
CPU 2 pc =3D 0xfffffc0000379188
CPU 2 ra =3D 0xfffffc0000379168
CPU 2 pv =3D 0xfffffc000059e520
CPU 2 curproc =3D 0xfffffc001ea3e018
CPU 2 pid =3D 253, comm =3D atalkd
panic: trap
Stopped in pid 253 (atalkd) at cpu_Debugger+0x4: ret zero,(ra)
db{2}> trace
cpu_Debugger() at cpu_Debugger+0x4
panic() at panic+0x160
trap() at trap+0x75c
XentMM() at XentMM+0x20
--- memory management fault (from ipl 4) ---
tlp_filter_setup() at tlp_filter_setup+0x528
tlp_ioctl() at tlp_ioctl+0xe4
ifioctl() at ifioctl+0x930
soo_ioctl() at soo_ioctl+0x1d0
sys_ioctl() at sys_ioctl+0x4dc
syscall_plain() at syscall_plain+0x158
XentSys() at XentSys+0x5c
--- syscall (54) ---
--- user mode ---
db{2}>=20
---------- end of console log.
If I'm not mistaken this is happening when the following instruction is
executed:
0xfffffc0000378f30 <tlp_filter_setup+528>: ldwu t0,66(sp)
=46rom "gcc -g -S output" this seems to be here:
$LM1276:
.stabn 68,0,2619,$LM1276
ldwu $1,66($30)
I.e. if I'm not mistaken that instruction was generated from within the
following code in sys/dev/ic/tulip.c:
2616 /* Pad the rest with our station address. */
2617 for (; cnt < TULIP_MAXADDRS; cnt++) {
2618 *sp++ =3D TULIP_SP_FIELD(enaddr, 0);
2619 *sp++ =3D TULIP_SP_FIELD(enaddr, 1);
2620 *sp++ =3D TULIP_SP_FIELD(enaddr, 2);
2621 }
Is this enough for a PR, or should I do a wee bit more debugging, and if
so, what further information would be useful?
Note that a quick test on a different host with a slightly different
card (shown below) doesn't trigger a panic -- at some point I can
arrange to try a test on this other host from boot to see if the problem
is reproducible on this different card:
tlp0 at pci1 dev 7 function 0: DECchip 21140 Ethernet, pass 1.2
tlp0: broken MicroWire interface detected; setting SROM size to 1Kb
tlp0: interrupting at dec 6600 irq 47
tlp0: DEC DE500-XA, Ethernet address 00:00:f8:1e:25:75
tlp0: 10baseT, 100baseTX, 100baseTX-FDX, 10baseT-FDX
[console]<root@whats> # ifconfig tlp0
tlp0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:1e:25:75
media: Ethernet 100baseTX full-duplex
status: active
inet 204.92.254.9 netmask 0xffffff00 broadcast 204.92.254.255
[console]<root@whats> # ifconfig tlp0 inet 204.92.254.9 delete
[console]<root@whats> # ifconfig tlp0 down
Oct 19 19:39:40 whats ntpd[225]: sendto(204.92.254.2): Network is down
[console]<root@whats> # ifconfig tlp0
tlp0: flags=3D8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:1e:25:75
media: Ethernet 100baseTX full-duplex
status: active
[console]<root@whats> # /etc/rc.d/atalkd forcestart
Starting atalkd.
Setting AppleTalk info with nbprgstr.
[console]<root@whats> # ifconfig tlp0
tlp0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:1e:25:75
media: Ethernet 100baseTX full-duplex
status: active
atalk 65280.250 range 1-65534 phase 2 broadcast 65280.250
[console]<root@whats> # /etc/rc.d/atalkd forcestop
Stopping atalkd.
[console]<root@whats> # ifconfig tlp0
tlp0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:1e:25:75
media: Ethernet 100baseTX full-duplex
status: active
[console]<root@whats> # ifconfig tlp0 inet 204.92.254.9
[console]<root@whats> # ifconfig tlp0
tlp0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:1e:25:75
media: Ethernet 100baseTX full-duplex
status: active
inet 204.92.254.9 netmask 0xffffff00 broadcast 204.92.254.255
(I note that in this example atalkd does bring the interface up again
all by itself, and of course this interface is active at the time too.)
--=20
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
--pgp-sign-Multipart_Thu_Oct_19_19:53:15_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 7B5twiPQNzQ4sU/bo1MfP44rb6UaIFmk
iQA/AwUBRTgP72Z9cbd4v/R/EQK2SwCfQ7PXEdcmgga3DbFB+kKdPnDU3f4AoMi8
t5zv9OGZLundt0JAKjKXU1i1
=VYT+
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Thu_Oct_19_19:53:15_2006-1--