> At a guess I would say that the kernel is not seeing interrupts from
> the card - does dmesg report the card on the same interrupt et al with
> the new and old kernels?

No, that's not the problem.

First, the machine with the new kernel sees the ARP packets from the other
systems. Second, even ISDN connections don't work - they establish the ISDN
connection, but can't get packets through. And I can assure you the kernel
needs to see several interrupts from the ISDN card before it will have an
ISDN layer 3 connection established.

It's a generic inet bug. Does it not manifest on other machines? Then I'll
have to dig into it, but I couldn't afford this machine to be down for
debugging yesterday.

The interfaces here are:

[~] martin@rumolt > ifconfig -a
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:80:c8:f9:e4:37
        media: Ethernet autoselect (none)
        status: active
        inet 212.8.203.81 netmask 0xfffffff8 broadcast 212.8.203.87
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32976
        inet 127.0.0.1 netmask 0xff000000
ipr0: flags=2811<UP,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
        inet 212.8.203.81 --> 192.168.110.42 netmask 0xffffffff
ipr1: flags=2810<POINTOPOINT,SIMPLEX,LINK1> mtu 1500
isp0: flags=a051<UP,POINTOPOINT,RUNNING,LINK1,MULTICAST> mtu 1500
        inet 212.8.203.81 --> 212.8.192.1 netmask 0xffffffff
isp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500

The multiple 212.8.203.81 interface have triggered a generic IP routing bug
before (the last-minute-fix which caused one of the first patches against
1.4 back then), somebody changed something in that area lately?


Martin