On Sat, 2010-09-04 at 09:27 +1000, Russell Stuart wrote: > On Mon, 2010-08-30 at 14:48 +0100, Ben Hutchings wrote: > > On Mon, 2010-08-30 at 17:34 +1000, Russell Stuart wrote: > > > The problem disappears in > > > linux-image-2.6.35-trunk-amd64_2.6.35-1~experimental.2. > > > > Yes, as I expected. > > > > Can you please test the attached patch against the version in unstable? > > Directions for rebuilding an official kernel package are at > > <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>. > > Applied that. It changed the problem. > > Before I got a nice repeatable BUG. Now the openvpn instance > unconditionally segfaults and normally nothing appears on the console or > in kern.log. Once I got "lucky" and this appeared on the console: [...] Are you quite sure you used the modified kernel? This message matches your original report: > kernel:[52062.330671] Code: 74 0f 48 89 ef e8 24 07 00 00 eb 05 > bb fe ff ff ff 89 d8 5b 5d 41 5c c3 48 85 ff 74 0e 48 8b 7f 30 > 48 85 ff 74 05 48 85 f6 75 04 <0f> 0b eb fe ba 02 00 00 00 e9 5d > ff ff ff 55 53 48 89 fb 48 c7 'cat /proc/version' will tell you for sure which version you are running. > The machine appears to freeze in various ways - eg you can't get a login > prompt to have a sniff around and the first command you type at an > existing shell prompt that requires disk IO freezes, and a "sleep 300; > sudo reboot -f" doesn't do anything. On the other hand a "for f in > $(seq 1000); do echo $f; sleep 1; done" continues on as though nothing > has happened. Disk IO is probably borked. The crash occurs at a point where the tun driver is holding the 'RTNL' lock which controls access to network device configuration. Any operation that must acquire that lock (and it's surprising how many operations do) will hang. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part